Combining Agile development philosophy and UX work hasn’t always been a match made in heaven. Many are the UX designers who’s been frustrated trying to work in an Agile environment, and there’s a few reasons for this.

Old Habits

Many of the practices we have, have been developed for Waterfall methodologies with clear silos and clear milestones. These processes has required a massive design documentation that have later been handed over to development to spend then next few months (or years) implementing.

Those practices doesn’t work anymore and they haven’t worked that well before either. As Agile has gone mainstream we as designers need to adapt to the Agile practices and rethink how we do our work.

But how do we do that?

One way is by reading Jeff Gothems book Lean UX, which explains how to incorporate a different, more lean, mindset to the UX process. He proposes a workflow with more focus on trying out hypotheses in the real world and less focus on creating deliverables.

Lean UX describes a way of doing UX work in an Agile fashion. It does so in a very clear and easy to digest fashion. Jeff draws from his long experience in leading agile UX work when he describes the pitfalls and opportunities.

So what is Lean UX?

Lean is all about reducing waste and it’s the same with Lean UX. The book outlines a few core principles to do this:

1. Less focus on producing design documentation, The value lies in delivering the product.
2. A focus on collaboration between Designers, Developers, QA and Business People. By breaking down the silos we get a much more effective design process and ultimately a better designed product.
3. The realisation that what we think are good solutions are just hypothesis that need to be tested in the real world. The key is to do this continously and effectively.
4. Design for outcomes instead of features. By focusing on the outcome the team is free to find the best solution to the problem instead of being locked down to a certain feature that might not be the optimal solution.

My verdict

Lean UX is an easy to digest, practical book on how to incorporate a more effective way of developing software. It provides both valuable insights and practical techniques. I highly recommend it for anyone involved in software development and by that I don’t mean just designers. I mean anyone involved.

Book information

Title:

Lean UX: Applying Lean Principles to Improve User Experience

By:

Jeff Gothelf and Josh Seiden

Publisher:

O’Reilly Media (March 8, 2013)

Pages:

152

ISBN:

1449311652

ISBN-13

978-1449311650

Buy on Amazon.com

Note: I wrote this review for O’Reilly’s Blogger Review Program. Their deal is pretty good: You get a free e-book to read and once you post a review you get another. Try it yourself if you’re interested in reviewing books.

We are no longer limited to the confides of our desktop computers for digital experiences. Digital is all around us in the form of Computers, Smart phones, Tablets and increasingly Smart TV’s. There’s even a whole slew of new devices waiting around the corner in the form of the Internet of things. That is everyday things that are connected to the Internet like scales, fitness tools and intelligent toasters.

Changing User Expectations

With access to all these devices, people are no longer satisfied with being restricted to just one. They want to do everything on the device that’s makes most sense for their current context.

The best computer is the one you have with you when you want something done Jakob Nielsen

Conventional wisdom says that mobile users are rushed and on the go. That’s a myth. People use their mobile phones in all kinds of contexts. Yes some of them are when they are rushed and on the go. But they also use them when they have some time to kill, or when they relax in the sofa at home after work. People even perform tasks on their mobile devices that’s not typically “mobile” tasks. See 40% of people use their phone in the bathroom and other interesting facts.

Building multi-device eco-systems

What this means is that we can no longer just think one application on one platform when we build software to solve a problem. We need to consider the bigger picture. How to solve that problem in a wider context. The future of computing lies in building eco-systems of applications for different devices that solves a particular problem.

But having to provide software on multiple devices. How do we design, build and maintain these without getting overburdened by the complexity and diversity?

Strong APIs

I’ve been thinking long and hard about this and the answer I’ve come up with is this: Build a strong and easy to use API with an eco-system of simple clients using it.

The trick here is to put as much of the complexity as possible in the API and make it as easy as possible for the clients to use it. This way the API is the piece you invest most in and that will live for a longer period of time. It will provide a foundation on which you can build relatively simple clients around.

The core of my thinking is that you need to make it as easy and painless as possible to build the client applications. New technologies comes and goes, who knows what the next wave of connected devices will be? Smart watches, smart glasses or something else? Whatever it is we need to make sure that we can be on that platform with relative ease, without having to start from scratch.

Go REST

I’ve been talking broadly about API’s here but what I advocate is to build a REST API.

REST is not a technology, it’s an approach. It relies entirely on HTTP for communication so it’s virtually technology agnostic. This is good. It doesn’t require you to use a specific technology to build clients. No matter what the technology, they will likely be able to communicate via HTTP.

Keeping it technology agnostic is a key aspect. Given that your API will live for a longer period of time, you can’t predict what new tech will be introduced, and you can’t predict which type of clients you will build a couple of years from now.

Use a simple Data Format

Just as you should invest in a solid API. You should invest in a robust data format. The format should be simple enough to not add a lot of overhead but capable enough to transfer fairly complex data models.

I’ve found JSON to be a good candidate for this. It’s simpler than XML (or SOAP [shudder]) but can communicate lists and nested objects. An additional benefit is that since it’s really a JavaScript object, it’s perfect for web applications.

Summary

To sum it up.

• We need to start thinking about building eco-systems of clients on different platforms rather than just thinking one application.
• To keep the cost down we need to invest in a solid API and a reliable data format. JSON being my choice of flavor.
• To keep the API technology agnostic, REST is a good approach. Since it relies on HTTP for communication virtually any programming language can talk to it.
• Putting the complexity in the API lets us focus on simple clients that are relatively easy to build and maintain.

I hope that I’ve got you thinking about how to approach building software for this new diverse and ever-connected world.

What’s your thoughts about this? I love to hear them in the comments.

The problem with bloated methods

The problem with bloated methods are twofold.

• They are hard to use since they require you to remember all arguments and the order they need to be supplied
• They are a pain to change. Adding an argument to an existing method can require you to find every instance where it’s used and update those calls with the additional argument.

Take this method for example.

var bio = function(id, name, description) {
  // Code
}

Ok, maybe it’s not that bloated. I actually think that using up to 3 arguments is OK, but add more than that and it’s getting messy. But for the sake of explanation let’s say it’s bloated and you want to remedy that.

A word about functions and methods

I’m talking about methods here but functions and methods are essentially the same thing. The only thing that differs is that a method is a function that’s part of an object. So in this example I assumes that the function being used is part of an object, hence the name method.

Objectify

Ok, so how do we get around this issue. The answer is simple – Use one options object instead of several arguments. It solves all of the problems listed above. Check this out:

• you don’t have to remember in which order to supply the arguments
• no need to supply all arguments on all calls
• easy to provide default values
• easy to expand the number of arguments without breaking functionality.

Ok so how’s this done then? Let’s take a look at the code for constructing the method.

var bio = function(options) {
  var id = options.id || -1,
    name = options.name || 'Empty',
    description = options.description || 'Empty';
}

The first thing you’ll notice is that instead of taking multiple arguments the method only takes one called options. But then you might be wondering what’s going on inside the function?

Inside the function is a check that make sure that the object has certain properties and saves those into local variables. If a property is missing, a default value is provided.

Calling the objectified method

Ok, so now you know how to create the method, but what about using it? Let’s look at some code.

// Creating an options object
var options = {
  id: 1,
  name: 'Luke Skywalker',
  description: 'Young talented man'
}

// Calling the method
bio(options);

In the code above an options object is first created and populated with the values that you want to pass to the method.

The options object is then used as the single argument when calling the method.

Note: The options object is created as an object literal which is a convenient way of creating objects on the fly.

Extending the object

Now, what if you need to add another argument?

No problem, just change your method to embrace the new argument.

You could do it in one of two ways.

• By providing default values
• By checking if the property exists and react accordingly.

The first way is how it’s implemented in the example so you just need to follow that same pattern.

The other way is sort of the same thing but a little different. Instead of providing a default value you can simply check if the property exists or not when you need to use it.

Let’s try that with a new argument: profession.

var bio = function(options) {
  var id = options.id || -1,
      name = options.name || 'Empty',
      description = options.description || 'Empty';

  if (options.profession) {
    alert(name + ' is a ' + profession);
  } else {
    // Some sort of fallback
  }
}

Now even if you call the method without supplying the profession property the code won’t break. Since we’re checking for its existence the method will handle it gracefully. This means that you don’t have to worry about breaking existing functionality.

Pro tip

You could make the call to the method more terse by creating the options object on the fly when calling the method, like this:

bio({
  id: 1,
  name: 'Luke Skywalker',
  description: 'Young talented man'
});

That’s how I usually do it, unless of course I need to use the options object for other things as well. Then it’s better to store it in a variable so you don’t have to create it all over again.

Conclusion

Passing arguments in an object instead of as individual arguments is a great way of improving your methods. It keeps your methods terse, extendable and easy to use. My recommendation is:

Whenever you find yourself with a method that requires more than 2 or 3 arguments, pass them in an options object.

Happy coding!

Note: This article has previously been published on Code Crafting Blueprints.

A base HTML

For the sake of explanation I’m going to use a simple HTML structure to illustrate how each selector works. It’s fairly simple and only contains a few basic elements:

<div id="wrapper">
  <h1>Big headline</h1>
  <p>Paragraph 1</p>
  <p>Paragraph 2</p>
  <div>
    <p>Paragraph 1 inside div</p>
    <p>Paragraph 2 inside div</p>
  </div>
</div>

It’s a simple structure but it will serve well for our purpose.

The DOM

I often find it useful to look at the HTML as a tree structure when trying to understand how different CSS selectors work. In fact, HTML forms a tree structure in the browser called the DOM – which is short for the Document Object Model.

The HTML structure above could be visualized like this:

As you can see some elements are below other elements and some elements sits side by side.<

It’s actually like a family tree and the relations between the elements are in fact called things like parent, child, sibling and descendant.

A recap of the most basic CSS selectors

To cover our bases I’m going to do a quick recap of the four most basic selectors. If you’re already familiar with these, feel free to skip ahead to the section about the combinators.

• The Universal Selector
• The Element Type Selectors
• The Class Selectors
• The ID Selectors

The Universal Selector

The Universal Selector is an asterisk (*) and applies to all elements in the DOM. It’s useful when you want to target several different element types.

* {
  margin: 0;
}

This selector would affect all of the elements in the DOM-tree:

An obvious use case for this selector is to create a simple CSS Reset. You can have this selector at the top of the CSS and set all the properites of all HTML elements to default values.

The Element Selector

p {
  margin: 0 0 1em;
}

The Class Selector

.first {
    color: #ff0080;
}

The ID Selector

Since there can be only one specific ID in a HTML document, the ID Selector always target a single element. It uses hash (#) and could look like this.

#wrapper {
  width: 980px;
  margin: 0 auto;
}

So far no surprises. You’re probably already familiar with these selectors and with that brief recap out of the way lets move on to more intesting things, namely the CSS Combinators.

The Combinators

The combinators are used in conjunction with the basic selectors. As the name suggest they enable you to combine other selectors in different ways so that you don’t have to have a class or ID on every single element that you want to target.

So why is this good then? Well it serves you well to keep the HTML and CSS as separated as possible. The least amount of extra attributes you have in the HTML the better. It will not only reduce the page size but also make maintenance easier.

To learn more about the benefits of keeping the HTML and CSS as separate as possible, read the article Separation of Concerns http://codecraftingblueprints.com/post/15732181414/separation-of-concerns which explores the benefits in greater deatail.

Now, lets move on to the combinators.

CSS Combinators

There are four different combinators in CSS and they each bring their own unique benefit:

• The Descendant Selector
• The Child Selector
• The Adjacent Sibling Selector
• The General Sibling Selector

The Descendant Selector

The Descendant Selector is just two or more selectors after each other, separated by whitespace. If for example you only want to target the <p> elements inside of the <div class="facts"> you could write:

.facts p {
  color: #ff0080;
}

With this code only <p> elements that lives below the element with the class="facts" are targeted.

The Child Selector

The Child Selector is a bit more specific than the previous one. It looks almost the same but you add a greater than character (>) between the two selectors. Doing this you make sure that only the elements that sits on the level immediately below the first selector are targeted.

#wrapper > p {
  color: #ff0080;
}

Now only the <p> elements immediately below <div id="wrapper"> are affected.

This is great for dealing with deeply nested structures where you want the styling to only target one level.

A common use case is when styling drop-down menus. These are often constructed with nested lists (<ul>) where you want the lists to have different styling depending on which level they appear.

The Adjacent Sibling Selector

The Adjecent Sibling Selector targets only elements that’s immediately after an element on the same level in the DOM-tree. It’s used by inserting a plus (+) between the first and the second selector.

h1 + p {
  color: #ff0080;
}

Now only the <p> that’s directly after the <h1> is affected.

A common use case for the Adjacent Sibling Selector is when you want the first paragraph in an article to have bigger text than the rest of the paragraphs. You could of course add a class such as .first to it but it’s nicer to not have to add extra attributes in the HTML. Instead you could write something like this:

p {
  font-size: 16px;
}
h1 + p {
  font-size: 24px;
  font-weight: bold;
}

The General Sibling Selector

The General Sibling Selector targets elements that are siblings, but unlike the Adjacent Sibling Selector, the targeted element doesn’t have to appear immediately after the first element. It’s constructed using a tilde (~) between the two selectors.

h1 ~ p {
  color: #ff0080;
}

Now both <p> elements are affected since they’re all on the same level as the <h1>.

Note that the affected elements need to appear after the target element. So if we have the HTML below, only the two <p> elements that appear after the <h1> will be affected.

<p>Paragraph 0</p><!-- This paragraph is not affected -->
<h1>Big headline</h1>
<p>Paragraph 1</p>
<p>Paragraph 2</p>

Conclusion

CSS Combinators are great for reducing the amount of extra classes and ID’s in your HTML and they have pretty good browser support too, at least if you target IE7 and above.

All of the combinators except the General Sibling Selector, are part of the CSS 2.1 specification which means that they’ve been around for quite some time. The General Sibling Selector is part of the CSS 3 specification but it still has really good browser support.

I hope that you will find CSS Combinators useful in your future CSS coding!

Can you think of more use cases for the combinators? Let us know in the comments!

Note: This article is previously published on Code Crafting Blueprints.

I have definitely been there and it’s equally frustrating each time. As the use of smart phones and tablets increases, so does the importance of having big enough target areas to interact with. But it’s not only important for mobile browsing. The truth is that it benefits desktop users as well.

Fitts’s Law

Fitts’s Law is a classic rule of thumb in Interaction Design. The law can be expressed in a fairly complex mathematical way but in a nutshell it states that the larger and closer a target is, the easier and faster it is to click it.

It’s not exactly Rocket Science, but still it highlights the importance of having, not only big enough targets, but also to position them intelligently.

If you want to know more about Fitts’s Law there’s an excellent explanation over at Particle Tree.

Designing for Touch

For touch devices, such as smart phones and tablets, a big enough touch target is even more important than on desktop. While a mouse pointer is a precision instrument with a click area of just 1 x 1 pixel, a human finger is more of a sledge hammer. The avarage size of the pad of a human index finger is 1.6 to 2 cm which translates to about 45-57 pixels on a screen.

You’ve probably experienced the frustration yourself when trying to click small links that are tightly packed on a smart phone. It can be really hard to hit the right target and that’s not the experience you want people to have with your web site.

Recommended touch target sizes

Apple iOS Human Interface Guidelines state that a touch target should be at least 44 x 44 points large. (The reason they’re using points instead of pixels is that points can be used for both standard and retina displays).

Microsoft’s Windows Phone UI Design and Interaction Guide suggest that the size of the touch target should be 34 pixels with an absolute minimum of 26 pixel. And Nokia’s Developer Guidelines state that the touch target should be at least 1 x 1 cm.

I actually I think that Nokia has the best guidelines since it states its minimum dimensions in cm. I mean 44 pixels can be very different on different screens and devices. Just think about the iPad and the iPad Mini. They both have the same amount of pixels but a click area of 44×44 pixels will be a lot smaller on the iPad Mini.

What you don’t have in size you can make up in space

Another interesting aspect of this is that if you absolutely do need to have relatively small touch targets you can partly compensate that by increasing the space between the targets. By doing that you limit the chance of missed targets.

The rule is: The smaller the target, the bigger the gap.

In Practice

Enough already, I think you get why it’s important to have big enough click/touch targets. The question is, how is it done in practice?

The first thing to recognize is that the clickable area could be well outside the visible area of the object.

Regular links

For links in a list, the easiest way to increase the clickable area, is to increase the padding. Instead of having a padding on the list-item you should have it on the link itself. In this example I simply add a 10 pixel padding to a link. Watch how that dramatically increases its clickable area (The faint red background indicates the clickable area).

li a {
  padding: 10px;
}

Checkboxes and Radiobuttons

For checkboxes and radiobuttons, which are often really small, the trick is to put them inside a label and add a generous padding to it. By connecting the checkbox and the label via the id and the for attributes, the entire area of the label is clickable and toggles the checkbox.

HTML

<label for="foo">
  <input type="checkbox" name="foo" id="foo" value="bar" />
  A padded checkbox
</label>

CSS

label {
  display: block
  padding: 10px;
}

Without this special treatment the click area is just the visible part of the checkbox while in the enhanced version the entire label is clickable. In this case this little tweak resulted in an over 50 times larger click area.

Summary

In this new brave world of multi-device experiences it’s more important than ever to cater for touch as well as mouse input. An easy way to do this is to provide big enough click targets. It’ll benefit not just user of touch devices but also desktop users.

This article shows a few simple techniques to do this. Of course there’s also other elements that these could be applied to but I leave it up to you to do that.

References

Online

• Finger-Friendly Design: Ideal Mobile Touchscreen Target Sizes
• Touch Target Sizes
• The Definitive Guide To Styling Web Links

Note: This article is a rewrite of the article Make Click Areas Comfortably Large that I’ve previously published on Code Crafting Blueprints.

Imagine that you have an affiliate site for the travel industry. You write beautiful articles which vividly describes exotic places where people could spend their holidays. Sprinkled in the text you have affiliate links to traveling agencies, which in case you didn’t know, have pretty decent kick-backs on referred customers that leads to a sale.

This might sound like common sense but you would be surprised to know how many sites that get this wrong. Often I think, for aesthetic reasons.

What to do about it

You don’t have to take it as far as usability guru Jakob Nielsen, who infamously claimed that links should be blue and underlined (which they are on his site useit.com by the way). I don’t want to push this issue that far (even though the links on this site are blue and underlined), but do make sure your links stand out from the rest of the text.

Your safest bet is probably to have them underlined. It carries a really strong affordance for clickability (check the Fast Facts Section for more on affordance). But you could also have them in a different color, a different background color and/or styled in some other way. Just make sure that they stand out from the rest of the text.

Note: Since underlined text is such a strong affordance for links on the web, you should make sure that everything that’s underlined is clickable. I.e. don’t underline text just to emphasize it.

Account for color blindness

Don’t forget that about 8% of the male population are color blind. Having something more than just the color to distinguish links is therefor a good idea.

Not just text links

The same thinking goes for other things that are clickable such as buttons, checkboxes, select lists, images etc. Make sure that these too actually look clickable.

For buttons that can mean to make them look like physical buttons with a 3D effect. This makes them stand out from the page and look more like physical objects.

Provide clues

Also make sure to provide other clues when the user moves the cursor over the object. The cursor itself could for example change to a pointing hand which carries a strong affordance of clickability. This happens by default over links in browsers but you could use a little CSS to create this effect on other clickable elements as well.

Another good idea is to make something happen with the clickable object itself when it’s being hovered. One common clue is to change the background color. This is easily achieved with the :hover pseudoclass in the CSS.

.clickable-item:hover { 
    cursor: pointer; 
    background-color: #ff9; 
}

Accomodate for keyboard

Some people prefer to use the keyboard instead of a mouse for one reason or the other. Don’t forget to take this into account when providing clues. Links and form elements are easily reachable by keyboard by just tapping the tab-key. For the user to know which element currently has focus, most browsers create a dotted outline around the element.

That’s a pretty good affordance, but you could make it even more clear. An easy thing that I often do is to make it have the same style as on :hover. This is easily accomplished with CSS by using the :focus pseudoselector.

.clickable-item:hover,
.clickable-item:focus { 
    cursor: pointer; 
    background-color: #ff9; 
}

Pro Tip: If you don’t like the dotted outline, you can get rid of it by setting outline to none in the CSS.

Don’t forget to design for touch

On touch devices there are no such things as a hover. It’s therefor extra important to make clickable objects look clickable. You will also want to make the click area bigger to accommodate for the fat-finger syndrome, but that’s a topic for another article.

Fast facts

Affordance

The term Affordance was popularized by Donald Norman in his seminal book The Psychology of Everyday Things. He later changed the term to Percieved Affordance since too many misunderstood what he meant by it. (Actually his latest term for this is Signifiers but that term hasn’t gained much traction yet)

The Percieved Affordance is the properties of an object we understand by just looking at it. For example a door knob communicates with its shape that it can be grabbed and turned. In a similar way we can, by just looking at a pair of scissors, see that the shape of the two “holes” looks like somewhere you can put your thumb and your hand.

The door knob affords grabbing and turning and the pair of scissors affords sticking your hands in the holes. In the same way a underlined link and a raised button affords clicking (or touching).

References

Online

• Guidelines for Visulizing Links
• Don Norman on Affordance

Note: This article is a rewrite of the article Make Clickable Things Look Clickable that I’ve previously published on Code Crafting Blueprints.

Scrum

I have mostly worked with Scrum, which I think is a great methodology for developing software. It brings a whole lot of good practices to the development process of which I think the most important is to bring the customer and the ones actually implementing the code closer to each other. Scrum really encourages better communication throughout the whole board.

UX brings value to the process

Allthough Agile is great a delivering software it lacks one important ingredients in creating successful product and services, the user. That’s an area where UX Design can bring a lot of value to the process. Great User Experiences doesn’t happen by accident. They happens because of focused efforts and that means bringing User Centered practices into the mix.

Agile and UX can definitely play nice together but there are no firm rules or definite best-practices on how to do it.

My talk

The talk was recorded and is available on YouTube. The presentation is available on SlideShare.

The Video

The Presentation

About Lean Tribe

Lean Tribe Gathering 12 was organized by Lean Tribe which is an organization that encourages discussions about Lean and Agile.

Performance That Matters

The percieved performance in this case is the most important factor. We therefore want the page to load progressively, meaning: The page renders from top to bottom as content is being downloaded.

Lets say you’re building an image gallery to show off your fabolous collection of Rainbow Unicorns. When the user clicks a unicorn a lightbox will open and display a bigger image of it.

Now, the CSS for the lightbox isn’t needed for rendering the page. It’s actually not needed until the user clicks an image. Therefore we could include it at the bottom of the page to let other content load first right.

- You know so that the page will render faster?

Wrong! Contrary to common sense it will actually delay the rendering of the page in a lot of web browsers.

Counterintuitive Behavior

But why does it delay the rendering? Keeping the browser from downloading it before other content ought to make the rendering faster. This is really counter intuitive at first glance, but listen to this:

The browser doesn’t want to risk having to re-render the page, it therefore waits until all CSS is loaded before rendering anything!

The Rule

Fortunately there’s a really simple solution to this. Just follow this simple rule: Include all CSS in the <head> of the page.

References

Books

High Performance Web Sites – Essential Knowledge for Frontend Engineers by Steve Souders

Online

Best Practices for Speeding Up Your Web Site

Note: This article has previously been published on Code Crafting Blueprints.

What you’ve experienced is what is commonly referred to as Spaghetti code. To avoid falling into this trap you should follow one simple rule:

Always separate HTML, CSS and JavaScript into different files.

Remember that HTML is for content (and structure), CSS is for design and JavaScript is for behavior. By separating them into different layers you gain several things. It becomes:

• Easier to maintain
• Increased performance
• Better accessibility
• A good foundation for SEO

Maintainability

First of all, your code becomes more maintainable. If there’s something wrong with the design, it’s probably in the CSS. If on the hand your super cool drag and drop interface stops working, something is probably wrong in the JavaScript files. In other words, it’s easier to find errors.

Imagine wanting to change the entire design of your site to a ninja unicorn theme (shudder). Having your HTML, CSS and JavaScript in a big mess you basically need to rewrite the whole site. But if you been a good coder and kept them separated, all you need to do is to change the CSS. Simple, right?

Performance

In most cases the site loads faster if you have the layers separated. And we all know how important speed is!

JavaScript and CSS files are static assets that can be effectively cached by the browser. What it means is that the browser doesn’t have to download them more than once. You save both bandwidth and rendering time.

Accessibility

By separating the different layers you also benefit the accessibility of the site. It’s in fact the foundation of Progressive Enhancement (and graceful degradation). This means that even if the user interact with your site using a less capable device (for example: disabled JavaScript, screen reader, old browser, you name it) it can still access the content because the device can simply ignore the parts it doesn’t support and render what it can.

HTML is the solid foundation of the web. By making sure that you keep the content there (semantically marked up of course) and that neither the CSS, nor the JavaScript is in its way, you can be sure that every browser on this planet can access your content.

SEO

Web crawlers, the evil robots of Search Engines that constantly crawles the web on their endless hunt for content to index, is another reason you want to separate the layers. A web crawler is basically a blind user. It doesn’t care about your fancy styles or your crazy JavaScript animations. All it cares about is your content – your HTML.

So you better make sure that your content is semantically marked up with valid HTML and that the CSS and JavaScript is out of its way. Having done this, you’re on your merry way towards SEO nirvana.

A Bad Example (Warning Anti Pattern!)

In this example, the separation of concerns is violated. Both content, style and behavior are meshed together in an awful soup.

HTML

<a href="/some/url/" onclick="someFunction(); return false;" style="font-size: 12px; color: #f00;">A bad link</a>

Good Example

Good Example

In this good example the same thing is done with a clear separation between content, style and behavior.

HTML

<a href="/some/url/" id="some_link">A good link</a>

CSS

#some_link { font-size: 12px; color: #f00; }

JavaScript

document.getElementById('some_link').addEventListener('click', someFunction, false);

Conclusion

I hope that this article have convinced you that keeping a clear separation is the way to go. So save yourself a lot of grief and separate these three levels as much as possible or you might as well end up in Spagetti Code Hell.

References

Online

The Web Standards model – HTML, CSS and JavaScript

Separation of concerns on Wikipedia

Books

DOM Scripting by Jeremy Keith, FriendsofEd 2005

Bulletproof Web Design by Dan Cederholm, New Riders 2006

Bonus Fact

The concept of Separation of Concerns is not limited to HTML, CSS and JavaScript. It applies just as much to general software development where you want to keep different things separated. For example the data, the business logic and the User Interface.

Separation of concerns on Wikipedia

Note: This article has previously been published on Code Crafting Blueprints.

About the author

The author of the book, Nancy Duarte, runs a company called Duarte that’s in the business of creating compelling presentations for their clients. They’re famous for creating Al Gore’s presentations for An Inconvenient Truth which was something that definitely showed the power of great use of presentation software.

Highly acclaimed

Since this book is widely praised in a lot of reviews I had pretty high expectations when I started reading it. Maybe that’s the reason I’m not so impressed with it. I found it pretty light on substance and I’m not sure it has added a lot of value to my slide creating skills.

The book touches on basic design principles and presentation skills. I’m sure if you’re a design noob that there’s a lot of nuggets to be found there, but if you have some design skills, it’s all very basic.

The format

The book is very “designed”, something I quite enjoy and I’m sure works very well in the physical book. The problem I had was that I read the e-book version in pdf format and the square format of the book with lots of design elements made it hard to read. I had to constantly zoom in on parts of pages to be able to read the text which made the reading experience less than ideal.

Summary

All in all I think it’s an OK book, which obviously a lot of work went in to creating. If you’re a non-designer you will probably find useful information that will make your slides better. But if you’re like me and have some experience in design and creating slides, you will find it very basic. That said you might still enjoy the design of the book and all the lovely examples in it. But in that case I recommend you get the physical book, because the e-book version is really not adapted for the format.

Book information

Title:

slide:ology: The Art and Science of Creating Great Presentations

By:

Nancy Duarte

Publisher:

O’Reilly Media; 1 edition (August 12, 2008)

Pages:

296

ISBN:

0596522347

ISBN-13

978-0596522346

Buy on Amazon.com

Note: I wrote this review for O’Reilly’s Blogger Review Program. Their deal is pretty good: You get a free e-book to read and once you post a review you get another. Try it yourself if you’re interested in reviewing books.