Recently the RAF Benevolent Fund (an awesome charity that supports families in the RAF) submitted their site for the CIPR Excellence Awards and blow me down if it didn’t win.

Although getting shinny awards is always nice, it was the comments they made that made us as pleased as punch…

The RAF Benevolent Fund project is an excellent example of the importance of clarity in all aspects of website development. The project was significant in scope, clear in its objectives, well executed and demonstrated its impact with measurable evidence. The aims of improved community engagement, increased online requests for help and greater online giving, were combined with a need to create one seamless platform that brought together all their digital assets. The RAF Benevolent Fund achieved all these aims through careful planning, detailed project management, a refreshingly collaborative approach from their designers and a clear and flexible technical implementation which provides a platform for future development.

It was so nice to see them talk about our “refreshingly collaborative approach”. For me this vindicates all I have been saying in Client Centric Web Design.

Thanks for subscribing to Boagworld; a web design blog, forum and podcast run by Paul Boag and friends.

If you are new to my feed may I recommend also:

• Following me on Twitter
• Checking out my get started guide
• Having a look through the archive of posts
• Subscribing to the podcast
• Visiting the forum
• Maybe even hiring me!

The 2-D Web-based game portfolio of Daniel Sternlicht.

Before getting down to business, let’s talk about portfolios.

A portfolio is a great tool for Web designers and developers to show off their skills. As with any project, spend some time learning to develop a portfolio and doing a little research on what’s going on in the Web design industry, so that the portfolio presents you as an up to date, innovative and inspiring person. All the while, keep in mind that going with the flow isn’t necessarily the best way to stand out from the crowd.

One last thing before we dive into the mystery of my Web-based game portfolio. I use jQuery which has made my life much easier by speeding up development and keeping my code clean and simple.

Now, let’s get our hands dirty with some code.

The HTML

Let’s warm up with a quick overview of some very basic HTML code. It’s a bit long, I know, but let’s take it step by step.

<div id="wrapper">

    
    <hgroup id="myInfo">
        <h1>DANIEL STERNLICHT</h1>
        <h2>Web Designer, Front-End Developer</h2>
    </hgroup>

    
    <div id="startCave" class="cave"></div>
    <div id="startCaveHole" class="caveHole"></div>

    
    <div id="mainRoad" class="road"></div>
    <div id="leftFence"></div>
    <div id="rightFence"></div>

    
    <div id="daniel"></div>

    
    <div id="aboutRoad" class="road side"></div>
    <div id="aboutHouse" class="house">
        <div class="door"></div>
        <div class=”lightbox”>…</div>
    </div>
    <div id="aboutSign" class="sign">
        <span>About Me</span>
    </div>

    
    …

    
    …

    
    <div id="rightTrees" class="trees"></div>
    <div id="leftGrass" class="grass"></div>

    
    <div id="endSea" class="sea"></div>
    <div id="endBridge" class="bridge"></div>

    <div id="boat" class="isMoored">
        <div class="meSail"></div>
    </div>

</div>

The HTML is not very complicated, and I could have used an HTML5 canvas element for this game, but I felt more comfortable using simple HTML DOM elements.

Basically, we have the main #wrapper div, which contains the game’s elements, most of which are represented as div elements (I chose divs because they are easy to manipulate).

Have a quick look at my game. Can you detect what makes up the game view?

The game view

We have roads, trees, fences, water, caves, houses and so on.

Back to our HTML. You’ll find an element for each of these items, with the relevant class and ID. Which brings us to the CSS.

The CSS

First of all, note that I prepared the HTML to follow the principles of object-oriented CSS by determining global classes for styling, and not using IDs as styling hooks. For example, I used the class .road on each element that should look like a road. The CSS for the .road class would be:

.road {
   position: absolute;
   background: url(images/road.png) repeat;
}

Take trees as another example:

.trees {
   position: absolute;
   background: url(images/tree.png) repeat 0 0;
}

Note that almost all of the elements are absolutely positioned on the game’s canvas. Positioning the elements relatively would be impossible for our purposes, especially because we want the game to be as responsive as possible (within limits, of course — the minimum width that I deal with is 640 pixels). We can write a general rule giving all of the DOM elements in the game an absolute position:

#wrapper * {
   position: absolute;
}

This snippet will handle all of the child elements inside the #wrapper div, and it frees us from having to repeat code.

One more word about the CSS. The animations in the game are done with CSS3 transitions and animations, excluding certain features such the lightboxes and player “teleporting.” There are two reasons for this.

The first is that one of the purposes of this portfolio is to demonstrate innovation and up-to-date development, and what’s more innovative than using the power of CSS3?

The second reason is performance. Upon reading Richard Bradshaw’s very interesting article “Using CSS3 Transitions, Transforms and Animation,” I came to the overwhelming conclusion: use CSS3 when you can.

A great example of the power of CSS3 animations in my portfolio is the pattern of movement of the water. The CSS looks like this:

.sea {
   left: 0;
   width: 100%;
   height: 800px;
   background: url(images/sea.png) repeat 0 0;
   -webkit-animation: seamove 6s linear infinite;   /* Webkit support */
   -moz-animation: seamove 6s linear infinite;      /* Firefox support */
   animation: seamove 6s linear infinite;          /* Future browsers support */
}

And here is the code for the animation itself:

/* Webkit support */
@-webkit-keyframes seamove {
   0% {
      background-position: 0 0;
   }
   100% {
      background-position: 65px 0;
   }
}

@-moz-keyframes seamove {…}   /* Firefox support */
@-keyframes seamove {…}       /* Future browsers support */

The sea PNG is marked out.

The repeating sea.png image is 65 pixels wide, so to give the sea a waving effect, we should move it by the same number of pixels. Because the background is repeating, it gives us the effect we want.

Another cool example of CSS3 animations happens when the player steps into the boat and sails off the screen.

The boat sails off the screen, revealing the “Contact” section.

If the player gets back onto the road, you’ll notice that the boat moves in “reverse,” back to its original position. It sounds complicated, but you have no idea how easy it is with CSS3 transitions. All I did was capture the event with JavaScript to determine whether the user is “on board.” If the user is, then we add the class .sail to the boat element, which make it sail off; otherwise, we withhold this class. At the same time, we add a .show class to the #contact wrapper, which smoothly reveals the contact form in the water. The CSS of the boat looks like this:

#boat {
   position: absolute;
   bottom: 500px;
   left: 50%;
   margin-left: -210px;
   width: 420px;
   height: 194px;
   background: url(images/boat.png) no-repeat center;
   -webkit-transition: all 5s linear 1.5s;
   -moz-transition: all 5s linear 1.5s;
   transition: all 5s linear 1.5s;
}

When we add the class .sail to it, all I’m doing is changing its left property.

#boat.sail {
   left: -20%;
}

The same goes for the #contact wrapper with the class .show. Except here, I’m playing with the opacity property:

#contact.show {
   opacity: 1;
}

CSS3 transitions do the rest of the work.

The JavaScript

Because we are dealing with a 2-D game, we might want to base it on a JavaScript game engine, perhaps an existing framework. But the thing about frameworks (excluding jQuery, which I’m using as a base) is that they are usually good for a head start, but they probably won’t fit your needs in the long run.

A good example is the lightboxes in my portfolio, which provide information about me and are activated when the user enters a house.

An example of a lightbox in the game. (Large image)

This kind of functionality doesn’t exist in a regular JavaScript game engine. You could always improve an existing framework with your own code, but diving into someone else’s code sometimes takes longer than writing your own. Moreover, if you rewrite someone else’s code, it could become a problem when a new version is released.

After passing over libraries such as Crafty, LimeJS and Impact, which really are great game engine frameworks, I felt I had no choice but to build my own engine to fit my needs.

Let’s quickly review the main methods that I’m running in the game.

To handle the keyboard arrow events, I use the following code:

$(window).unbind('keydown').bind('keydown', function(event) {
    switch (event.keyCode) {
        event.preventDefault();
        case 37: // Move Left
            me.moveX(me.leftPos - 5, 'left');
        break;

        case 39: // Move Right
            me.moveX(me.leftPos + 5, 'right');
        break;

        case 38: // Move Up
            me.moveY(me.topPos - 5, 'up');
        break;

        case 40: // Move Down
            me.moveY(me.topPos + 5, 'down');
        break;
    }
});

As you can see, the code is very simple. When the user presses the up or down arrow, I call the moveY() function, and when they press right or left, I call moveX().

A quick peek at one of them reveals all the magic:

moveX: function(x, dir) {
    var player = this.player;
    var canMove = this.canImove(x, null);
    if(canMove){
        this.leftPos = x;
        player.animate({'left': x + 'px'}, 10);
    }
    if(dir == 'left') {
        this.startMoving('left', 2);
    }
    else {
        this.startMoving('right', 3);
    }
}

At each step the player takes, I check with a special method named canImove() (i.e. “Can I move?”) to determine whether the character may move over the game canvas. This method include screen boundaries, house positions, road limits and so on, and it gets two variables, including the x and y coordinates of where I want the player to move to. In our example, if I wanted the player to move left, I’d pass to the method their current left position plus 5 pixels. If I wanted them to move right, I’d pass its current position minus 5 pixels.

If the character “can move,” I return true, and the character keeps moving; or else, I return false, and the character remains in their current position.

Note that in the moveX() method, I’m also checking the direction in which the user wants to go, and then I call a method named startMoving():

if(dir == 'left') {
   this.startMoving('left', 2);
}
else {
   this.startMoving('right', 3);
}

You’re probably wondering how the walking effect on the character is achieved. You might have noticed that I’m using CSS sprites. But how do I activate them? It’s actually quite simple, with the help of a jQuery plugin called Spritely. This amazing plugin enables you to animate CSS sprites simply by calling the method on the relevant element and passing it your properties (such as the number of frames).

Back to our startMoving() method:

startMoving: function(dir, state) {
   player.addClass(dir);
   player.sprite({fps: 9, no_of_frames: 3}).spState(state);
}

I simply add a direction class to the player element (which sets the relevant sprite image), and then call the sprite() method from Spritely’s API.

Because we are dealing with the Web, I figured that being able to move with the keyboard arrows would not be enough. You always have to think of the user, your client, who might not have time to hang out in your world. That is why I added both a navigation bar and an option to “teleport” the character to a given point in the game — again, using the canImove() method to check whether the player may move to this point.

Next we’ve got the lightboxes. Recall what the HTML looks like for each house:

<div id="aboutHouse" class="house">
   <div class="door"></div>
   <div class="lightbox">
      <div class="inner about">
         Lightbox content goes here…
      </div>
   </div>
</div>

Did you notice the .lightbox class in the house div? We will use it later. What I basically did was define a “hot spot” for each house. When the player gets to one of those hot spots, the JavaScript activates the lightboxInit(elm) method, which also gets the relevant house’s ID. This method is very simple:

lightboxInit:  function(elm) {
   // Get the relevant content
   var content = $(elm).find('.lightbox').html();

   // Create the lightbox
   $('<div id="dark"></div>').appendTo('body').fadeIn();
   $('<div id="lightbox">' + content + '<span id="closeLB">x</span></div>').insertAfter("#dark").delay(1000).fadeIn();
}

First, I get the relevant content by finding the div.lightbox child of the house element. Then, I create and fade in a blank div, named dark, which gives me the dark background. Finally, I create another div, fill it up with the content (which I had already stored in a variable), and insert it right after the dark background. Clicking the “x” will call another method that fades out the lightbox and removes it from the DOM.

One good practice that I unfortunately learned the hard way is to keep the code as dynamic as possible. Write your code in such a way that if you add more content to the portfolio in future, the code will support it.

Conclusion

As you can see, developing a 2-D Web-based game is fun and not too complicated a task at all. But before rushing to develop your own game portfolio, consider that it doesn’t suit everyone. If your users don’t have any idea what HTML5 is or why IE 5.5 isn’t the “best browser ever,” then your effort will be a waste of time, and perhaps this kind of portfolio would alienate them. Which is bad.

Nevertheless, I learned a lot from this development process and I highly recommend, whatever kind of portfolio you choose, that you invest a few days in developing your own one of a kind portfolio.

(al)

© Daniel Sternlicht for Smashing Magazine, 2012.

The "I Wish" CSS Only Technique

What would be nice is if you had simple semantic HTML like this:

<a href="http://github.com">GitHub</a>

And then you could access everything you needed to insert a background image of the favicon using a service like getFavicon.

/* Fair warning, this doesn't work */

a[href^="http"]:before {
  content: url(http://g.etfv.co/ + attr(href) + );
}

Maybe the syntax wouldn't be exactly like that, but something like it. The point is, you can't mix up the url() syntax into parts like that in CSS.

Google's Favicon Service

Google has it's own favicon service you can use. For example:

http://www.google.com/s2/u/0/favicons?domain=css-tricks.com

The trick is you need just the host name and TLD and nothing else. I searched around and found a simple regex for getting that from any URL. We'll need that because links aren't always (or even usually) the root of sites.

function getDomain(url) {
   return url.match(/:\/\/(.[^/]+)/)[1];
}

Using these things, and jQuery, we'll find all links and apply the favicon as a background image. The external link checking is pretty rudimentary, but there are more robust methods here if need be.

$("a[href^='http']").each(function() {
    $(this).css({
        background: "url(http://www.google.com/s2/u/0/favicons?domain=" + getDomain(this.href) +
        ") left center no-repeat",
        "padding-left": "20px"
    });
});

Then @travis reminded me that you can just use this.hostname instead of the fancy regex. So:

/* Nothing else needed */
$("a[href^='http']").each(function() {
    $(this).css({
        background: "url(http://www.google.com/s2/u/0/favicons?domain=" + this.hostname +
        ") left center no-repeat",
        "padding-left": "20px"
    });
});

I'm not sure what the browser support is for hostname, whether it's just as good as href or less so, not sure.

getFavicon Method

@seanodotcom showed me another similar service galled getFavicon. It's hosted by Google AppEngine, but it's not Google's own service. I did find it a bit slower. But the advantage being that you don't need to deal with host names at all, you just give them the full URL.

So then it becomes:

$("a[href^='http']").each(function() {
    $(this).css({
        background: "url(http://g.etfv.co/" + this.href + ") left center no-repeat",
        "padding-left": "20px"
    });
});​

View Demo

Performance?

As I'm sure you know, the number of HTTP requests a page makes is a huge deal in performance. Each little image in these techniques are one page request each.

@yuritkanchenko pointed out to me a cool favicon service that can automatically sprite the favicons for you so you can keep it to one request.

For instance:

http://favicon.yandex.net/favicon/google.com/yandex.ru/css-tricks.com

I'm afraid I didn't go the extra mile here and write the JavaScript needed to find all links, concatenate the domains, make the request, and then apply the images as a sprite, but I'm sure you could whip that up pretty quick if you really needed it.

Favicons Next To External Links is a post from CSS-Tricks

For those who aren’t familiar with the term in this context, “specs” is short for specifications — in the case of design, they are instructions that specify colors, fonts, sizes, spacing and so on, just like a blueprint. Specs are a crucial part of the design and development process for companies with big teams and for small companies that have to outsource some of their development. Specs function not only as instructions to developers, but also as a reference point to make sure the whole team is on the same page.

However, the process of producing specs is repetitive and time-consuming, especially for creatives. But now this can all change: Specctr, together with Adobe Fireworks, offers a quick and easy way to generate this important information automatically.

The Idea

My idea to make Specctr came from my personal experience working on a design team at a large corporation. Spec’ing was part of my routine. One day, after hours of spec’ing, my eyes hurt and I was bored and frustrated. Suddenly, I realized that this kind of intensive work should be automated, and that a designer’s time is much better spent designing rather than spec’ing.

Specctr is more than a tool: it is a business solution for any company whose designers must generate specs for developers. Specctr facilitates this communication and leaves designers and developers happier and more productive. Making this process quicker frees up the business to focus more intently on its core mission.

Possible time saved using Specctr for Adobe Fireworks.

Time saved using Fireworks and Specctr Pro.

In the process of creating Specctr, I brought my design background and practical experience in spec’ing to bear on the issues and opportunities in automating the process. Meanwhile, my colleague, Dmitriy Fabrikant, engineered the software from the ground up. Working in tandem at On Pixel, we released Specctr Pro in January 2012. Since then, it has received many favorable reviews.

Specctr Lite

In addition to the commercial version of the tool, we’re happy to release a free version called Specctr Lite as a contribution to the community. We chose to highlight width and height as well as text spec’ing abilities, because they are most common to a designer’s workflow. These two feature sets alone will save a lot of valuable time.

The Lite version includes:

• Width and height
• Text spec (font family, size, color)
• Expand canvas feature

Specctr Lite can be downloaded for free from our website, and we’re happy to say that it was created and released as a result of the involvement of Smashing Magazine!

Pro and Lite: a quick comparison

The Lite version is as easy to use as the Pro version, and its features work the same way.

Requirements And Installation

To use Specctr (Pro or Lite), you need:

• A Mac or PC
• A copy of Adobe Fireworks CS3, CS4, CS5 or CS5.1

The installation process is pretty straightforward:

1. Download the Specctr installer
2. Double-click the MXP file to open the Adobe Extension Manager
3. Click on “Install”
4. Restart Adobe Fireworks
5. In Fireworks, go to Window → Specctr to open the Specctr panel.

Please note: If you are using Windows Vista or 7, you might need to launch the Adobe Extension Manager as Administrator, otherwise the extension could fail to install.

If you still have questions, don’t hesitate to consult our online tutorial (PDF, 1.9 MB) or contact us directly!

Specctr Pro

A Brief How-To Guide

Once you install Specctr through the Adobe Extension Manager, restart Fireworks, and then open Specctr from the Window menu. Now that Specctr is open, you can spec a document in a few easy steps.

First, prepare your document by making room for your specs. Select the size of your design’s border, and click on the “Expand Canvas” button.

Select which details to display by toggling them on or off from the panel’s menu.

Now Specctr Pro will automatically display your spec with a click of the button.

To spec a shape (shape, line, dot, etc.) or a text object, select the object (or multiple objects), and click on the “Spec Object” button. The specs will be outputted to the nearest edge of the canvas.

Properties of objects in a spec

You can also spec the spacing between two objects by selecting them and then clicking the “Spacing” button. If you select only one object, Specctr will measure the object’s distance to the edges of the canvas.

Measuring the space between objects

Finally, you can also spec the width and height of any object.

Insight Into The Fireworks Extension Development Process

The process of developing Fireworks extensions consists of the following steps:

1. First, we design and build the panels in Adobe Flash Pro.
2. We import the panels into Flash Builder and add the ActionScript code, which makes them run.
3. Finally, we have to connect with the Fireworks API, which is written in JavaScript, in order to manipulate Fireworks.

Because the development process is spread over three separate environments, integrating the different pieces of the application and debugging the application present some challenges. But in the end, it’s well worth the positive response from our users.

In the next couple of weeks, Dmitriy will release on GitHub a few ActionScript libraries that he has built during the process of developing Specctr. These libraries will hopefully reduce some of the pain points of the tiered development process. We might also write another article that highlights in more detail the development process for building a Fireworks extension.

One of Fireworks’ strengths is its potential as a development platform that leverages the creativity and innovation of its community. We would love to help this process and show that Fireworks is a powerful tool for Web design.

Further Reading

Here are a few useful resources related to extending Adobe Fireworks:

Extensions

• Aaron Beall
• John Dunning
• Matt Stow
• Orange Commands, Ale Muñoz

Other Resources

(al) (mb)

© Chen Blume for Smashing Magazine, 2012.

Whether you are a designer, developer, content strategist or business owner, at the Smashing Conference you’ll explore insights hands on and gain practical tips and new perspectives on our craft. We are very happy to provide an opportunity for you to share and gain practical knowledge in an intimate, informal atmosphere — right in our beautiful home town of Freiburg, Germany, at the foot of the legendary Black Forest.

The legendary Historical Merchants Hall, a late-Gothic building built between 1520 and 1530. Its façade is decorated with statues and the coat of arms of four Habsburg emperors. An exquisite location for the very first Smashing Conference. Image credit.

When and Where?

We’re delighted to invite you to come together for this inspiring, forward-thinking event on 17 to 19 September 2012. The conference will host a two-day single-track conference on September 17th and 18th, as well as three workshops on September 19th. By “we,” we mean Vitaly Friedman, editor-in-chief of Smashing Magazine, and Marc Thiele, who has been running community events such as beyond tellerrand for over 12 years.

The aim of the event is to deliver the same high-quality content that we deliver on Smashing Magazine, in the familiar atmosphere that beyond tellerrand events are known for. This will be a high-caliber yet friendly event that brings great value to everyone involved, and we’d be honored if you took a part in it.

The conference will take place in Freiburg, Germany at the legendary Historical Merchants Hall at the foot of the Black Forest.

The main hall of the venue. 350 tickets are available in all for our two-day single-track event. Image credit

Keeping the conference affordable for everyone is important to us. All tickets includes two full single-track conference days, on Monday and Tuesday. Please note that only 350 seats are available.

We are pleased to announce that the first 70 early-bird tickets are on sale for a price of €249. The regular price after that is €349. And all prices include the German VAT of 19% and booking fees! Get your ticket now before it’s too late. We’d be honored to meet you in September!

Speakers and Topics

If you’ve been following Smashing Magazine for a while, then you won’t be surprised by the focus of the Smashing Conference. We’re aiming to cover a wide variety of Web design topics, such as visual design, front- and back-end development, UX design, mobile, responsive design, the business aspects of running a website, as well as the intricate details of the designer and developer’s workflows. We’re encouraging our dear speakers to share details on how they work, what tools they use, and what their design and coding process looks like. We’re aiming for valuable, practical and inspiring talks.

We’ve handpicked all of the speakers to ensure the high quality of the event. So far, 10 out of 15 speakers are officially confirmed. Please note that the topics presented here are subject to change. More details on the conference, speakers, talks and workshops are available on the conference’s official website.

Speakers

Speaker	Talk	Details
Aarron Walter	The Real Me
Aarron Walter is the lead user experience designer for MailChimp, where he socializes with primates and ponders ways to make interfaces more human. Aarron is the author of Designing for Emotion, the purple stripe in the rainbow of knowledge from A Book Apart. He lives with his wife and son in Athens, Georgia, and is a wannabe barista. He tweets about design under the moniker @aarron.
Chris Heilmann	To be announced
Chris Heilmann has dedicated a lot of his time to making the Web better. Originally from a radio journalism background, he built his first website from scratch in around 1997, and he spent the following years working on a lot of large international websites, and a few years at Yahoo building products and training people; he is now at Mozilla. Chris has written and contributed to four books on Web development and has written many articles and hundreds of blog posts for Ajaxian, Smashing Magazine, Yahoo, Mozilla, ScriptJunkie and many more.
Jeremy Keith	The Spirit of the Web
Jeremy Keith makes websites. He is responsible for the death of the trees used to print the books DOM Scripting, Bulletproof Ajax and, most recently, HTML5 for Web Designers. He also shot a man in Reno just to watch him die. Originally from Ireland, Jeremy now lives in Brighton, England where he pretends to work with Clearleft. Peas grow there.
Jonathan Snook	Your CSS Is a Mess
Jonathan Snook writes about tips, tricks and bookmarks on his blog. He has also written for A List Apart, 24ways, and .net magazine, and he has coauthored two books, The Art and Science of CSS and Accelerated DOM Scripting. Most recently, Snook has written the eBook SMACSS, sharing his experience and best practices on CSS architecture. Snook also works on the design team at Shopify.
Josh Brewer	Responsive Is as Responsive Does
Josh spends his time thinking about, designing and building things that live at the intersection of form, function and aesthetic. He is principal designer at Twitter and is the co-creator of 52 Weeks of UX, Ffffallback and Shares. He is also an advisor and mentor at The Designer Fund.
Lea Verou	To be announced
Lea has a long-standing passion for open Web standards and has been often called a CSS guru. She loves researching new ways to take advantage of modern Web technologies, and she shares her findings on her blog. Lea also makes popular tools and libraries that help Web developers learn and use these standards. She speaks at a number of well-known international Web development conferences and writes for leading industry publications. Lea also co-organized and occasionally lectures in the Web development course at the Athens University of Economics and Business.
Paul Boag	Better Websites, Happier Clients and Improved Job Satisfaction
Paul Boag has been working on the Web since 1993. He is Web Strategist at Headscape Ltd, a Web design agency that he cofounded back in 2002. Paul also produces and hosts the longest-running and award-winning Web design podcast at boagworld. He is a regular speaker at conferences and author of Client-Centric Web Design.
Rachel Andrew	The Future of Content Management
Rachel Andrew is a front- and back-end Web developer, author and speaker. Her books include the bestselling CSS Anthology for SitePoint, and she is a regular contributor to a number of publications both online and off, including Smashing Magazine. She writes about business and technology on her own website.
Stephen Hay	To be announced
Stephen has been designing and developing for the Web since 1995. He currently helps clients with front-end design and development, multi-platform strategy and accessibility through his consultancy, Zero Interface. Aside from his client work, he can be found speaking at industry events about Web design-related topics such as CSS layout and responsive design workflow. Stephen is co-organizer of Mobilism, one of the world’s leading mobile Web development conferences. He is also co-creator of Grip Workshops, a series of two-day intensive workshops for Web project managers on the client side. Stephen has written for publications including A List Apart and .net Magazine. He also coauthored the Smashing Book 3 with a host of super-talented folks. When he makes the time for it, he publishes his thoughts on The Haystack.
Tim Ahrens	Web Fonts Backstage and On Stage
Tim Ahrens is a type designer based in Berlin, where he runs Just Another Foundry with Shoko Mugikura. As a former architect, he is interested in the interplay between technology and design. He develops design software such as the Font Remix Tools and Web applications such as the FontFonter. Since 2010, he has been working as a consultant for Typekit.

Gallery of the speakers at the Smashing Conference.

Workshops

Trainer	Workshop	Details
Aarron Walter	Interface Design Bootcamp
Whether you are designing a Web app or website, following best practices and standard design methodologies will help ensure that your interfaces are usable and engaging. In this workshop, we’ll explore the design process in detail, including user research, wireframing, prototyping and visual design. Through real-world examples, you’ll see how an idea can evolve into an interface.
Andy Clarke	Fashionably Flexible Responsive Web Design
Responsive design has made designing flexible websites fashionable again, but there is more to being fashionably flexible than technology or using CSS3 media queries. So, this unique workshop — hosted by Andy Clarke, designer, author and speaker — puts the design back into responsive design. Andy will teach you how to design from the “content out,” instead of from the “canvas in.” He’ll demonstrate how to separate design from layout; and if you work with designs made in Photoshop, he’ll show how to deconstruct a design into its components (color, texture and typography) before reassembling it for a fluid continuum of devices, from phones to desktops and everything in between.
Jonathan Snook	SMACSS: Scalable and Modular Architecture for CSS
The SMACSS workshop is a full day of instruction and exercises on writing HTML and CSS using a flexible and modular approach that will improve team efficiency and minimize problems with growing projects. It brings the eBook to life with practical examples and in-depth discussion.

Gallery of the workshop experts at the Smashing Conference.

Further Details About the Conference

As we finalize some major details of organization, we are working hard on a plethora of small details to make the event as valuable and memorable as possible. Please expect more speakers to be confirmed soon and more topics to be announced.

Also, we are looking for sponsors of the event, so if you are interested, please get in touch with us. More details on the location, hotels, speakers, talks, workshops and after party are presented on the official Smashing Conference website.

One of the workshop rooms, with medieval decoration and statues of medieval knights. 30 seats are available for each workshop. Image credit.

Facts

• In a nutshell: The Smashing Conference is a friendly, valuable and inspiring community event that will help designers and developers become better in their work, be it front- or back-end development, UX design, content strategy or running a business.
• Dates: 17 to 19 September 2012 (workshops on the 19th, and conference on the 17th and 18th).
• Venue for workshops and conference: “Zum Roten Bären”, Historical Merchants Hall, Freiburg.
• Early-bird price (only 70 tickets): €249 ($315) (including German VAT and fees).
• Regular price: €349 ($440) (including German VAT and fees).
• Each workshop costs €349 ($440) (including German VAT and fees).
• Twitter: @smashingconf
• Lanyrd: http://lanyrd.com/2012/smashingconf/
• Facebook: http://www.facebook.com/smashingconf
• Website: http://www.smashingconf.com

“Zum Roten Bären“, one of the locations for the conference’s workshops. Large view.

We’re very excited about the Smashing Conference, and we’ll do our best to make it a valuable, memorable and useful event. We can’t wait to meet you, and please feel free to contact us if you have any questions about participation or sponsorship.

© Smashing Editorial for Smashing Magazine, 2012.

1. You want the icon to enhance a word
2. You want the icon to stand alone but still be functional or informational

And our major goals here are:

1. As good of semantics as we can get
2. As little awkwardness for screen readers as possible

This ground has been treaded before, but I think the following techniques are a small step forward.

Enhancing a word

Let's say we have a header like "Stats" and we want to set it apart from other headers on the page and emphasize it's meaning. Semantic ideal:

<h2 id="stats" class="stats-title">Stats</h2>

Result:

So to get that icon in there (remember we're talking font icons here, we can't just pad the left and use a background) we'll need to insert some content.

Using a pseudo element is tempting because 1) they aren't read by most screen readers 2) we don't need dedicated markup for the icon which is a semantic ideal. Unfortunately, VoiceOver on OS X does read the content of pseudo elements. (reference 1, reference 2) Well, perhaps "fortunately" as if I'm reading the spec correctly that's what it is supposed to do. Psuedo elements just aren't in the DOM and thus that probably makes it harder for third-party apps to do.

The good news is that if we use a bit of markup, we can use aria-hidden attribute to prevent it from being spoken.

One more dash of bad news, even with aria-hidden on the markup surrounding the icon, VoiceOver on OS X will announce "HTML Content" when in focus. #dammit.

But alas! We can still win here. If we combine the markup technique and pseudo element technique, we can insert the icon with no VoiceOver weirdness. And as a double-win freebie, this combined technique is ideal for keeping our CSS lean and mean as it requires no class-name-bloat and works well with the next use case we need to cover.

So the final markup for this becomes:

<h2 id="stats">
  <span aria-hidden="true" data-icon="&#x21dd;"></span>
  Stats
</h2>

And the CSS is:

[data-icon]:before {
  font-family: icons; /* BYO icon font, mapped smartly */
  content: attr(data-icon);
  speak: none; /* Not to be trusted, but hey. */
}

Holy cow that's easy eh? Notice we aren't using a specific class name for the icon (e.g. like .icon-stats or something), we're using a data-* attribute to hold exactly which character we want to insert. In our icon font, we map those special characters to the icon we want to use. I find this perfectly semantic and even future proof (you could always select uniquely down the line even if you change the character). But if you prefer class names, more power to you, that's fine and doesn't change this technique drastically.

We'll cover mapping characters at the end.

Stand-Alone Icons

Say we have an icon that is a link or in some way functional, but it isn't accompanied by any text. For instance, a shopping cart icon that you can click to go to your shopping cart. Hopefully that functionality is obvious visually, with some kind of rollover state or general design obviousness. But that functionality also needs to be audibly obvious.

Instead of crafting a totally new technique to deal with this (which I've dabbled with in the past) let's lean on what we've already started. A span that inserts the character with a pseudo element, and text that sits right next to it that we kick off the page visually.

<a href="#rss" class="icon-alone">
  <span aria-hidden="true" data-icon="&#x25a8;"></span>
  <span class="screen-reader-text">RSS</span>
</a>

We need very little in additional CSS, just a little usability fix applied via class, and a toolbox class for hiding the text but leaving it accessible.

.icon-alone {
  display: inline-block; /* Fix for clickability issue in WebKit */
}
.screen-reader-text { /* Reusable, toolbox kind of class */
  position: absolute;
  top: -9999px;
  left: -9999px;
}

Hey, it works

View Demo

In VoiceOver, anyway. Would be great to hear from people who use other screen readers how this holds up.

Building / Mapping Your Icon Font

One "issue" in the world of icon fonts right now is that the majority of them available come pre-mapped to letters. Used with improper markup, the letters become "content" and a part of the semantics of the document. Or worse, read outloud by screen readers.

It almost never makes sense for an icon to be mapped to a letter. Instead, I recommend mapping icons to the closest unicode symbol you can find. For instance, mapping a heart icon to ❤ is a splendid idea. The meaning of symbols is rather relative anyway, so close counts and will be a semantic improvement immediately.

Even better, I like the idea of mapping icons to the "Private Use Area" of Unicode. As I understand it, this is exactly why it exists, to use for your own special characters. Mapped this way, you're in no danger of the character being spoken by a screen reader. Unfortunately at the time of this writing icons mapped this way don't work in even the latest Safari, so it's not yet recommended. Here's the scoop on the Private Use Area issues paraphrased from Keyamoon:

There is a difference between PUA (Private Use Area) and SPUA (Supplementary Private Use Area). The difference is explained a bit here. In my testing, PUA mapping works perfectly in all browsers. SPUA mapping borks in Safari only on Windows. The IcoMoon app only maps to PUA, which is recommendable at least for the short term future.

Here are the steps to follow:

1. Pick out an icon font.
2. Go to IcoMoon and load it up (or use their icon set)
3. Choose the icons you want.
   
   
4. Map them to the characters you want. Best to map to a relavant symbol or PUA.
   
5. Download the fonts/demo.

You can also use Pictos Server to do the icon-picking and mapping, but it only works with Pictos and doesn't help you with choose symbols (you could copy and paste from here). It is a very nice set though and hosts for you and makes it very easy to existing sets without manually swapping out font files.

The Future

In the future, hopefully we can rely on speak: none; working perfectly everywhere so we can go back to using pseudo elements and perfect semantics.

HTML for Icon Font Usage is a post from CSS-Tricks

1. Colorburned — 32 Amazing Minimalist Website Layouts
2. DesignFestival — Top Minimalist Website Designs: Trends and 23 Examples
3. Desizn Tech — Why minimal web design works? 6 Examples and analysis
4. Hongkiat — 100+ Clean, Simple And Minimalist Website Designs
5. Line25 — 50 Inspiring Examples of Minimalism in Web Design
6. Six Revisions — 40 Beautiful Examples of Minimalism in Web Design
7. Six Revisions — 30 Beautiful Clean and Simple Web Designs for Inspiration
8. Smashing Magazine — Showcase Of Clean And Minimalist Designs (40+ examples)
9. Smashing Magazine — Principles Of Minimalist Web Design, With 80+ Examples
10. Speckyboy — 20 New and Free Minimal WordPress Themes
11. Speckyboy — 35 Effective Examples of Minimalism in Web Design
12. Splashnology — 35 Examples of Minimalism in Modern Web Design
13. SpyreStudios — Showcase of 20 Minimalist Grid-Based Web Designs
14. SpyreStudios — 56 Light & Clean Website Designs Using A Minimalist Color Scheme
15. Tripwire Magazine — 50 Best Responsive WordPress Themes
16. Web Design Ledger — 25 Fresh Examples of Minimalist Web Designs

That should get you going, let me know if you know of any that should be added to the list :)

Related posts:

1. Series Summary: Minimalist Web Design Showcase
2. Minimalist Web Design Showcase: Equivocality
3. Minimalist Web Design Showcase: ShaunInman.com

If you expect a “user-friendly” introduction to usability and that the history of usability is full of well-defined concepts and lean methods, you’re in for a surprise. Usability is a messy, ill-defined, and downright confusing concept. The more you think about it—or practice it—the more confusing it becomes. We learned that the history of usability is a “perverse journey from simplicity to complexity”.

What Is Usability?

Early Roots of Usability

If we go far back in history, Vitruvius (1st century BC) was probably the first person to lay forth systematic and elaborated principles of design. His three core design principles became very influential:

1. Firmitas: The strength and durability of the design;
2. Utilitas: A design’s usefulness and suitability for the needs of its intended users;
3. Venustas: The beauty of the design.

Vitruvius’ work was an inspiration to people like Leonardo da Vinci, who drew the well-known Vitruvian Man (fig. 1 below). By empirically measuring and calculating the proportions of the human body, and emphasising the “utilitas” principle, Vitruvius may be considered the first student of ergonomics and usability.

Figure 1: The Vitruvian Man drawing was created by Leonardo da Vinci circa 1487 based on the work of Vitruvius.

Military Roots

The discipline of usability is also rooted in the discipline called Human Factors, which started as military personnel asked themselves the very morbid question:

“What design do we need to kill more enemies through better matching soldier and weapon? And thus avoid getting killed ourselves.”

Both World War I and World War II fueled research into Human Factors. When designing artillery cannons, for example, usability yielded more precision, greater kills, and shorter training of personnel.

Thus, military designers could extract some very concrete usability metrics. For example:</>

• How quickly will a new crew member learn how to use the artillery cannon (now that the former crew member is dead)?
• How many rounds per minute (ordnance) is the cannon able to fire with an inexperienced versus an experienced crew?
• How will improving the design of the cannon improve target acquisition (and thus kill more enemies)?
• How does a design improvement decrease soldier fatigue (as a consequence of a lighter cognitive load)?

Figure 2: Photograph of the French 320 mm railway gun Cyclone, taken in Belgium in 1917. The gun required not only trained personnel to fire it, but also trained personnel to drive it.

Figure 3: A 155 mm artillery shell fired by a United States 11th Marine Regiment’s M-198 howitzer. The setup time (and thus usability) is essential as anti-artillery weapons necessitate that the position of the howitzer be changed very quickly after firing.

Recent Roots of Usability

The concept of usability has its more recent and direct origins in the falling prices of computers in the 1980s, when for the first time it was feasible for many employees to have their own personal computer. In the 80s, most computer users had practically no, or only basic, training on operating systems and applications software. However, software design practices continued to implicitly assume knowledgeable and competent users, who would be familiar with technical vocabularies and system architectures, and also possess an aptitude for solving problems arising from computer usage.

Such implicit assumptions rapidly became unacceptable. For the average user, interactive computing became associated with constant frustrations and consequent anxieties. Computers were obviously too hard to use for most users, and often absolutely inpractical. Usability thus became a key goal for the design of any interactive software that would not be used by trained technical computer specialists.

The current understanding of usability is different from the early days in the 1980s. Usability used to be a dominant concept but this changed with research increasingly focused on usage contexts. Usage quality no longer appeared to be a simple issue of how inherently usable an interactive system was, but how well it fitted its context of use.

Usability Evaluation: What’s Good And What’s Bad?

Usability is a contested historical term that is difficult to replace. User experience specialists have to refer to usability, since it is a strongly established concept within the IT landscape. In simplified terms, usability work is about finding out what’s good and what’s bad. However, when we examine the hundreds of usability evaluation methods in use, we do see that different approaches to usability result in differences over the causes of good and poor usability. That may sound complicated but let’s take two different approaches to usability:

1. If you think usability is a feature of an interactive system, your approach to usability may be called essentialist—i.e. poor/good usability resides in the “essense” of the system. You will typically find yourself saying things like “that website is not user-friendly”, “a website or system has poor usability when there is no visibility of system status”, “I can reliably measure which website has the best usability”, etc. This means you think that all causes of user performance are due to technology. In that case, you will typically use system-centered usability inspection methods to identify such causes.
2. On the other hand, if you think usability is a feature of the interaction between user, computer and the context, your approach to usability is contextual—i.e. depending on the context. This means that you think questions of user performance have different causalities, some due to technologies, and others due to some aspect(s) of usage contexts, but most due to interactions between both. Several evaluation and other methods may be needed to identify and relate a nexus of causes. You will often find yourself saying vague things like “that depends…”, “well… this website checkout procedure is great for male, fact-oriented, middle-aged buyers, but not for an impatient teenager doing the purchase on his smartphone sitting in the bus”, etc.

The reason I mention the essentialist/contextual distinction is that anyone involved with usability should—ideally—be able to say “this website/technology/system is good, that one is bad”. After all, isn’t that what your client or boss is paying you to do?

To answer if the usability of a website is good or bad you have to employ a usability method. And your choice of usability method will depend on your approach to usability—whether you admit it or not. Maybe you’ll deny it and say, “I’ve never heard of any essentialist/contextual approaches to usability.” However, that would be like selling French wine without ever having spent time in a French vineyard. You can do it, but at some point your client or boss will start asking questions you can’t answer. Or your decisions will have unexpected side-effects.

So what usability method should you choose to determine “what’s good and what’s bad”?

Analytical And Empirical Evaluation Methods

Usability work can involve a mix of methods and the mix can be guided by high level distinctions between methods, for example the distinction between analytical and empirical evaluation methods.

1. Analytical evaluation methods are based on examination of an interactive system and/or potential interactions with it. You analyse the system or analyse the interaction with the system.
2. Empirical evaluation methods, on the other hand, are based on actual usage data.

Analytical evaluation methods may be system-centred, like Jakob Nielsen’s Heuristic Evaluation or interaction-centred, like the Cognitive Walkthrough method. Design teams use the resources provided by a method (e.g. heuristics) to identify strong and weak elements of a design from a usability perspective.

Three types of analytical evaluation methods:

• Inspection methods tend to focus on the causes of good or poor usability.
• System-centered inspection methods focus solely on software and hardware features regarding attributes that will promote or obstruct usability.
• Interaction-centered methods focus on two or more causal factors (i.e. software features, user characteristics, task demands, or other contextual factors).

Figure 4: Jakob Nielsen’s Heuristic Evaluation is a good example of an analytical evaluation method. Heuristic Evaluation became the most popular user-centered design approach in the 1990s, but has become less prominent with the move away from desktop applications.

Empirical evaluation methods focus on evidence of good or poor usability, i.e. the positive or negative effects of attributes of software, hardware, user capabilities and usage environments. User testing is the principal project-focused method. It uses project-specific resources such as test tasks, users, and also measuring instruments to expose usability problems that can arise in use. Also, empirical experiments can be used to demonstrate superior usability arising from user interface components (e.g. text entry on mobile phones) or to optimise tuning parameters (e.g. timings of animations for windows opening and closing).

Such experiments assume that the test tasks, users and contexts allow generalisation in regards to other users, tasks and contexts. Such assumptions are readily broken, e.g. when users are very young or elderly, or have impaired movement or perception.

How To Balance The Mix: Why Is It Difficult?

Achieving a balanced mix of evaluation methods is not straightforward, and involves more than simply combining analytical and empirical methods. This is because there is more to usability work than simply choosing and using methods.

Evaluation methods are as complete as a Chicken Fajita Kit, which contains very little of what is actually needed to make Chicken Fajitas: no chicken, no onion, no peppers, no cooking oil, etc. Similarly, user testing ‘methods’ miss out equally vital ingredients and project-specific resources such as participant recruitment criteria, screening questionnaires, consent forms, test task selection criteria, test (de)briefing scripts, target thresholds, data analysis methods, or reporting formats.

There is no complete published user testing method that novices can pick up and use ‘as is’. All user testing requires extensive project-specific planning and implementation. Much usability work is about configuring and combining methods for project-specific use.

Figure 5. Chicken Fajita Kit. Copyright Old El Paso. All rights reserved.

The Only Methods Are The Ones That You Complete Yourselves

When planning usability work, it is important to recognise that so-called ‘methods’ are simply loose collections of resources better understood as ‘approaches’. There is much work in getting usability work to work, and as with all knowledge-based work, methods cannot be copied from books and applied without a strong understanding of fundamental underlying concepts. All methods must have unique usage settings that require project-specific resources. For user testing, for example, these include participant recruitment, test procedures and (de-)briefings. There are no universal measures of usability that are relevant to every software development project.

The Position So Far

1. There are fundamental differences on the nature of usability, i.e. it is either an inherent property of interactive systems, or an emergent property of usage. There is no single definitive answer to what usability ‘is’.
2. There are no universal measures of usability and no fixed thresholds above or below which all interactive systems are or are not usable. There are no universal, robust, objective and reliable metrics. All positions here involve hard won expertise, judgement calls, and project-specific resources beyond what all documented evaluation methods provide.
3. Usability work is too complex and project-specific to admit generalised methods. What are called ‘methods’ are more realistically ‘approaches’ that provide loose sets of resources that need to be adapted and configured on a project by project basis.

Readers could reasonably draw the conclusion from the above that usability is an attractive idea in principle that has limited real-world application. However, the reality is that we all continue to experience frustrations when using interactive digital technologies, and even we would say that we find them difficult to use. Even so, frustrating user experiences may not be due to some single abstract construct called ‘usability’, but instead be the result of unique complex interactions between people, technology and usage contexts.

Usability In The Design Room

In well directed design teams, there will not be enough work for a pure usability specialist. This is evidenced by a trend within the last decade of a broadening from usability to user experience expertise. User experience work focuses on both positive and negative value, both during usage and after it. A sole focus on negative aspects of interactive experiences is becoming rarer. Useful measures of usage are extending beyond the mostly cognitive problem measures of 1980s usability to include positive and negative effect, attitudes and values, e.g. fun, trust, and self-affirmation. The coupling between evaluation and design is being improved by user experience specialists with design competences.

Many user experience professionals have also developed specific competences in areas such as brand experience, trust markers, search experience/optimisation, usable security and privacy, game experience, self and identity, and human values. We can see two trends here. The first involves complementing human-centered expertise with strong understandings of specific technologies such as search and security. The second involves a broadening of human-centered expertise to include business competences (e.g. branding) and humanistic psychological approaches (e.g. phenomenology, meaning and value).

As such, a usability person is not a lone judge who makes the call “is this usable?” Instead, the usability proficient person will often be a team player taking on many roles in the product development lifecycle.

Figure 6 A-B. From Solo Specialist to Team Member: User Experience—as opposed to Usability—as an integrated part of design teams. Copyright of leftmost picture: Flickr user ‘Tety’ through the Creative Commons Attribution Share-Alike 2.0 licence

Conclusion: Are You Confused?

This Smashing Magazine article is a digested version of the monstrous 25,000 word encyclopedic introduction to the history of Usability Evaluation at Interaction-Design.org. It’s available in a special version for Smashing readers.

Did this article confuse you more than it informed you? Well, it should! If you want an answer to the question of “what is usability?”, it’s just as complicated as asking “what is beauty?” The more you think about it, the less you feel you know. I don’t believe you will ever find the answer to the question “what is usability?”, but I nevertheless hope you—as I—will continue to ask that very question. And be confused again and again. Confusion is—after all—the mother of wisdom.

The concept of usability is a product of millions of designers trying for decades to describe what they are doing to make technology easier and more pleasant. As such, the concept is immensely complex. It may have started out as a simple concept but the more people who are involved with usability, the more multi-faceted the concept will become. Therefore, the history of usability is a journey from simplicity to complexity. Is that journey worth the effort? Certainly! Anyone who masters usability—and all its facets—has a power position when it comes to designing easy/pleasant/cool/useful/usable/etc. technology. As confusing as that endeavour may be!

(jc) (il)

© Mads Soegaard for Smashing Magazine, 2012.

Advertise here with BSA

Here at WDL, we really like minimalism and we believe that the “less is more” principal can result in amazing websites. Minimalism, explained as the essence of something, is when we reduce something to its necessary elements. What is the right amount of elements to compose a minimal design is a polemic subject, but we can all agree that having few elements make a layout elegant, easy to understand/use and pleasant to see. Today we gathered a few examples of minimalistic designs to inspire you, check it out.

b14

Eleven Made

Elliot Jay Stocks

12th of Never

Academy

Teacake

It’s Numbered

Irving & Co

Socket Studios

Regenerate Music Co

FO

Antidote

twenty8twelve

Visual Supply Co

Andy Chak

Oliver Spencer

fruute

Pollen

François Deladerriere

grain&gram

Studio Octopi

The Best Designs
Minimal Sites