    
|
|
|
Templates are one of the key tools at any developers disposable. They make it easier for us to build complex websites that are maintainable and easy for other developers to understand. With the exception of a few JavaScript frameworks, most templating is done on the server. When a request comes in to the server the templating engine pieces together the relevant templates and sends the constructed page down to the browser. This is great for a lot of use cases but with the increasing popularity of applications that run solely on the client-side we need a robust solution for handling templates in the browser. Enter the new HTML <template> element.
The <template> element allows developers to create client-side templates made up of chunks of reusable DOM. The key thing about HTML templates is that they are inert. Your templates are not rendered by the browser until you activate them using JavaScript. This also means that any content they contain (images, video, audio) will not be loaded or played until the template is put to use.
It’s also worth noting that content within a template is not considered part of the main document. Trying to select an element within a template from the main document object will not work. Instead you first have to select the template and then use querySelector() to access the element you want to target. You will see an example of this later.
The <template> element is currently supported in Chrome, Firefox and Opera (15+).
You can detect support for HTML templates by checking to see if the content property is present on a <template> element. Here is an example:
if (‘content’ in document.createElement(‘template’)) {
// Templates are supported.
} else {
// Templates are not supported.
}
Creating a template is pretty straight-forward. All you need to do is create a <template> element and give it an appropriate ID.
Lets take a look at an example template that could be used for a blog comment.
<template id="comment-template">
<li class="comment">
<div class="comment-author"></div>
<div class="comment-body"></div>
<div class="comment-actions">
<a href="#reply" class="reply">Reply</a>
</div>
</li>
</template>
Here we create a template with the ID comment-template. Our template’s content consists of a list item (<li>) with a number of <div>s that contain the comment author, body and a link for users to write a reply.
You can also include CSS and JavaScript within your templates using the <style> and <script> elements.
In order to use your template you will need to write a little JavaScript. Lets take a look at an example.
var tmpl = document.getElementById('comment-template');
document.body.appendChild(tmpl.content.cloneNode(true));
Here we start by getting a reference to our <template> element using it’s ID and store this in a variable named tmpl. In this example we are not manipulating anything within the template so we just create a copy of the it’s content (tmpl.content.cloneNode(true)) and add this to the document.body.
Now that we’ve covered the basics I think you’re ready to move onto something a little more complex.
In this next example we are going to render a series of blog comments using a template. Lets assume that there is an unordered list (<ul>) element in the main document that we want to add our comments to.
Note: I’ve created a variable named comments that contains an array of comment objects for us to play around with. In reality you would probably be loading this data via AJAX.
// An array of comments.
var comments = [
{'author': 'Joe', 'body': 'I love this product.'},
{'author': 'Mary', 'body': 'Great idea. I have got to get me one of these!'},
{'author': 'Eric', 'body': 'These things are fantastic. I bought three.'}
];
// Get a reference to the comments list in the main DOM.
var commentsList = document.getElementById('comments');
// Loop through each of the comments and add them to the comments list.
for (var i = 0; i < comments.length; i++) {
var comment = comments[i];
var tmpl = document.getElementById('comment-template').content.cloneNode(true);
tmpl.querySelector('.comment-author').innerText = comment.author;
tmpl.querySelector('.comment-body').innerText = comment.body;
commentsList.appendChild(tmpl);
}
Here we start by getting a reference to the comments list in the main DOM.
We then loop through the items in the comments array. Each time we create a new variable called comment and initialize it with the appropriate comment in the array. This just makes the code a little more readable.
We then select our <template> element and make a clone of the content using content.cloneNode(). This just means that we can add our text without changing the original template.
Next we find the <div> elements that should contain the comment author and body by calling the querySelector on our tmpl variable. Then we update the innerText properties of these elements so that they contain the author and body content.
Finally we add our cloned template content to the commentsList using the appendChild method.
Comments Rendered Using HTML Templates
In this blog post you have learned how to use the new HTML <template> element to define chunks of DOM that can be reused by your applications. Although browser support is currently confined to Chrome, Firefox and the latest release of Opera I’m optimistic that we will see support emerging in other browsers too.
It’s worth remembering that as HTML templates rely on the use of JavaScript, user’s with browsers that have JavaScript disabled will not be able to see the content rendered using templates. This problem also affects some older screen-readers. It’s important to think this through and provide fallbacks for assistive technologies where appropriate.
The post Creating Reusable Markup with The HTML Template Element appeared first on Treehouse Blog.
]]>|
|
A basic understanding of version control has become a necessity for everyone working with code, no matter if you’re a software developer, a web designer, or even a graphics designer who has to work with developers in a team.
Apart from the have-to-know aspect, however, there are also a number of reasons why you should want to use a version control system (VCS).
Version control makes collaboration in a team easier. Without a version control system, everybody on the team is probably working on the same shared set of files. It’s only a matter of time until someone overwrites someone else’s changes.
Also, a VCS takes care of combining changes from different people into one common version. In version control nomenclature, this is called merging. As a result, working on the same files simultaneously becomes safe and easy.
But even when you’re working on your own, a VCS still has plenty of benefits.
For example, version control makes storing and restoring versions of your project a lot easier.
Without a VCS, you’re probably saving versions of your files and folders using your own adventurous naming scheme, resulting in a horrifically unmanageable number of files and folders with file names like website-relaunch-homepage_2013-10-11_v3_JenniferSmith.html.
With a VCS in place, you only have a single project folder on your disk. All other versions and variants are safely stored in your version control system’s database, neatly described, and ready to be restored any time you want them.
Last but not least, one of the best aspects about using a VCS is that it serves as documentation, and also helps promote the act of documentation.
Since each major change is wrapped in a commit (more about this term later), and each commit is described with a message, you can very easily follow along and understand the incremental changes in a project. This becomes even more useful when problems arise and you have to find out where they originated.
A ton of version control systems are available on the market, each with their own pros and cons.
However, there are many reasons why you should choose Git.
Git, for one, is arguably the most popular open source version control system out there right now.
As a decentralized version control system, Git offers:
Another big advantage of Git is its superior branching management. Although other version control systems also know the concept of branches, Git was really built around it, and thus it provides a super-fast and easy branching experience. Once understood, making use of this concept can really take code quality to another level.
Other concepts, like the Staging Area or the Stash, also contribute to making Git a very useful part of your coding tool belt.
When choosing any tool, you should also keep another factor in mind: Popularity. A tool without adoption in the market, without a community, is most often badly documented, can’t be integrated with other systems, and is not sure to survive in the long run.
Git has already arrived in the mainstream. With projects like the Linux kernel, Ruby on Rails, jQuery, and many other major open source projects, as well as big companies (such as Google, Facebook, and Twitter) using it, both of Git’s quality and its longevity are proven.
Installing Git has become incredibly easy in recent times (lucky you!).
There are one-click installers for both Mac and Windows.
To follow along with this guide, please install Git on your computer first.
Also, having our free Git cheat sheet handy will be useful before we begin delving into Git.
With the Git cheat sheet, you don’t have to remember all the Git commands by heart, and it will allow you to deviate from this guide and explore Git on your own.
After completing the Git installation, it’s time to fire up your command line.
Two basic configurations should be made before you get started: Your name and your email.
To set your name and email, issue the two following Git commands, but modify them so that you’re using your own name and your own email address:
$ git config --global user.name "Your Name"
$ git config --global user.email "your@email.org"
There are two ways to start working on a project with version control: cloning an existing repository and creating a new repository.
When you’re getting on board of a project that’s already running with a version control system, you were probably provided with a URL to the project’s repository on a remote server.
What’s a repository? A repository is just a fancy term for a project’s set of files and folders.
For example, check out jQuery’s repository on GitHub:
To get a copy of a project’s repository on your local computer, use the git clone command, like this:
$ git clone https://github.com/gittower/git-crash-course.git
The command above will download the respective repository located at https://github.com/gittower/git-crash-course.git to your computer.
Note: If you don’t have a repository, feel free to clone from the above Git command example and fiddle with the test repository that it contains. You can also browse through open source projects on GitHub, find a repository that’s interesting to you, and then clone it to your computer.
The other possibility to getting started with version control is when you already have an existing project that is currently not under version control yet.
Navigate into the project’s root folder with the command line, and then use the git init command to start versioning this project:
$ git init
You might be wondering where Git stores all the data about your repository.
In both scenarios that I talked about — cloning an existing repository or creating a new repository — you should now have a hidden folder inside your project’s root folder. That folder is your local Git repository, and that folder’s name is .git.
You can verify this by issuing the ls Unix command like this:
ls -la
Knowing that this folder exists is more than enough. You should not touch anything inside this magical folder.
When working on your project’s files, you’ll have a great deal of peace of mind, and it will help liberate your creative and experimental thinking.
You don’t have to be fearful any longer about making changes to your files: modify, delete, add, copy, rename, or move them using whatever application you prefer (such as your favorite editor, a file browser, etc.).
Git will allow you to undo changes when necessary, and it won’t affect anyone else working on the same file.
It’s only when you feel you’ve reached a noteworthy state that you have to mind version control again.
At this point, when you have reached a good stage in your work, it’s time to wrap up your changes in a commit.
A commit just means submitting the changes you’ve made to your files, to your repository.
My recommendation and a good practice: As the first step to making a commit, give yourself an overview of what you’ve changed.
You can easily see an overview of your changes with the git status command:
$ git status
After issuing a git status command, Git will list all changes since you last committed, grouped into various categories.
Here’s our working example output after issuing the git status command:
You might be unfamiliar with a couple of terms in the working example output above:
Now is the time to mark the changes you want to wrap up in the next commit. In Git lingo, this process means you’re staging your changes.
How do you stage your changes?
git add command for modified and untracked files.
git rm to confirm the deletion of a file.
git add -A command.From our working example above, here’s how you would stage the index.html file (which was modified), the new-page.html file (which is untracked), and the two modified files in the css folder:
$ git add index.html new-page.html css/*
Here’s the command confirming that you’d like to delete the error.html file:
$ git rm error.html
If you look at the output of the git status command from our working example above, you’ll see that, additionally, the imprint.html file was modified. I deliberately didn’t stage it with the git add command, because I want to leave it for a later commit.
Again, I suggest taking a look at what git status tells you before finally making the commit.
Here’s the output of our working example now, after I’ve staged the files I want to commit:
The Changes to be committed paragraph informs you about what you just staged.
To save this set of changes in a commit, you only have to use the git commit command with a good, descriptive message that tells you and others what the commit is about, right after the -m option, like this:
$ git commit -m "Implement the new login box"
If you want to see what happened in the project so far, you can get an overview with the git log command:
$ git log
This Git command lists all recorded commits in chronological order.
Congratulations! By now, you’ve already grasped the most important concepts of version control and Git.
To get your Git knowledge to the next level, I suggest the following steps.
A lot of tasks can be performed easier and more comfortably using a desktop client application, let alone not having to memorize all of the commands and parameters.
Windows users might want to have a look at Tortoise Git, while Mac OS users can give Tower a try, the Git desktop client my team and I have created to make Git easier to use.
In recent years, the amount of documentation, tutorials, and articles on Git has increased a ton.
Read these resources to become better at using Git:
Version control has become an integral part in the modern developer’s workflow.
While version control used to be a chore in the past, systems like Git not only makes version control dead-simple, but also provides a lot of other workflow benefits.
Tobias Günther is CEO and founder of fournova. In 2010, he set out to make Git easier to use: Together with his team, he develops the Git desktop client, Tower for Mac.
The post How to Quickly Get Started with Git appeared first on Six Revisions.
]]>|
|
Do you cringe at the mention of a “brief”? It’s just a document for clients and “suits,” right? Wrong!
A brief has the potential to be the single biggest factor to determine your profit margin, which means you should care about them.
Creating a great design brief takes extra effort and time, yet a tight brief can save a designer up to 20% of the project’s timeline. If you’re working on a fixed-fee project, then that adds up to hundreds, if not thousands, of dollars saved.
If you’re being paid for time and materials, then you won’t necessarily be losing money, but we all know how soul-destroying getting negative feedback and constant requests for changes can be, all because of a poor brief. It causes frustration for both the designer and the client.
Don’t be afraid to ask questions. Ask as many as possible, and keep asking until you are satisfied that you understand what your client’s brief is. A great way to do this is by using a briefing template that you know and trust and that you feel has all of the necessary questions (so that you don’t forget to ask certain ones). Don’t just email the template to your client. Go through it with them. Discuss each question and even fill it in for them.
Explain to the client the importance of the brief. Your clients are probably busy people, too, and so they might not appreciate the importance of spending extra time creating a brief.
Collaborate. The more people involved in a design project (this could include more than one person on the client’s side, as well as the designer, the account manager, the creative director), the more important the brief becomes. Make sure that you all collaborate on the brief, so that by the time it is approved, everyone who is involved will understand what is required and what the brief is.
Always put the brief in writing. If you’re a freelancer, then you might not like this one. Just taking a verbal brief from the client is often quicker and easier. While discussing the brief is important, a written document gives you more cover and helps to protect your profit margin. If you’ve ever heard a client say, “I think you misunderstood what I meant” or “I don’t recall saying that,” then you’d know that having the brief in writing is the only option.
Have one brief, in one place. The best way to explain this is with a scenario. I’m sure many of you have experienced this: the client provides a written brief, and you meet (or Skype) to discuss it. Cool — you know what they want. A few days later, you receive an email with a few updates. Then the client calls to change something else. You’re now a week into the project, and the written brief you received is out of date, and keeping track of the phone calls and email conversations is getting confusing. What was the brief that the client approved? Keeping the brief in one place where all communication is documented will help to keep the project on track and keep disputes to a minimum.
Put your brief in the cloud. Annotating a PDF or tracking changes in Microsoft Word gets messy. Long email trails and forgotten conversations are even messier. You’re a web designer, so use the web for your briefs. It will increase your productivity, your client’s productivity and your bottom line.
Briefs are never going to be the “exciting” part of web design, or any creative process. However, spending time developing a brief properly and giving it the care it requires, all the way to its final approval, leads to several things:
Sounds simple, right? Take a few moments to think about your briefing process. Could it be improved? Are you wasting time and money because of poor or lazy briefs? The time to improve your briefing process is now.
How do you manage your briefs? Do you use formal documents? Let us know in the comments.
Featured image/thumbnail, briefing image via Shutterstock.
| 8 Downloadable Web Design Courses – 90% off! |  |
|
|
Building a staging environment on Heroku is pretty straightforward, especially now they’ve released their new ‘fork’ feature.
To fork your app and ensure that all your assets, environmental variables, and Postgres databases are cloned, simply run:
heroku fork -a yourapp yourapp-staging
I also recommend automatically deploying the staging server whenever you push to master. This is convenient, as it means you have a up-to-date version of your app always running. Your can test on staging, and then deploy production a couple of times a day.
To automate staging deploys follow the instructions on the github-heroku-pusher project. A GitHub webhook POSTs to your deploy server, which will then deploy your staging environment in the background.
]]>
 |
We all make mistakes. Whether in our design and development work or just in life in general, we all do it. Thankfully, even the biggest mistakes carry valuable lessons.
As a contrast to the many Web design articles that focus on successes and what we can learn from those triumphs, this article looks to the other end of the spectrum to explore what failures teach us.
Along the way, I will share stories of some of the missteps I have made in the course of my career and the lessons I’ve learned in the process — being ever mindful of composer John Powel’s words:
“The only real mistake is the one from which we learn nothing.”
Anyone who has been designing and developing websites for any amount of time has come up with a process for working. Having a process is good, but be careful that it does not overshadow the project itself or the people involved.
I was reminded of this a few years ago in a project that was going badly. The simple reality was that I was not getting along with the project manager who was appointed by the client. Our personalities clashed almost from the start, as I found her feedback and requests to be misguided and her personality abrasive. At the same time, I am sure she found me unhelpful and combative because I was unwilling to honor all of her requests.
As frustration grew, I tried to fall back on our process as a way of adding structure to the relationship and trying to get it back on track. If she made a request that took us outside of our normal process, I explained how we could not do it without setting the project back in both time and budget. The worse the project got, the more I deferred to our process, until the client, exasperated to the limit, told me that I seemed to care more about our process than the project.
My plan had backfired. I had tried to lean on our process in order to fix the problems, instead of having a difficult confrontation and dealing with the real issue — the fact that personality clashes were becoming strained to the point that nothing was being accomplished.
Eventually, we reset the project by calling for a meeting to clear the air and address the problems honestly so that we could move forward. While I continued as the project lead on our side, I brought in another team member, someone who did not have a rocky history with the client’s project manager, to handle the day-to-day communications. Even though she acted as little more than an interpreter for me in many cases, the fresh voice and personality from our side did wonders for the relationship, and the project manager responded to our new team member much better than she had to me.
Additionally, we looked at the client’s requests a little more deeply and, rather than dismissing them outright because they deviated from our normal process, tried to identify the reasoning behind each request so that we could honor them in the spirit in which they were made (which we normally do anyway). We realized that those requests didn’t really affect our normal process in a big way. Any deviation was minor, and the relationship and the project were much better off with the flexibility in our process.
People are more important than the project, which is more important than the process.
Of course, you need to strike a balance. A process exists for a reason, and if you abandon it whenever anyone shows resistance, then there is little point in having a process at all. That being said, any good process has some flexibility to accommodate the different needs of clients and projects.
Lesson learned: Followed blindly, no process will save you from having to deal with difficult personalities or bumps in the road. A process is meant to help a project along, not to be hidden behind when the going gets tough. For additional reading on client communications, see my previous articles, “Keys to Better Communication With Clients” and “How to Deliver Exceptional Client Service.”
I frequently speak with clients about their website needs. I listen to their concerns and the issues they’re having with their current website, and I tell them how we can meet their needs. Note that I said I “tell” them how we can help, when I should usually be showing what we can do for them.
This might not seem like a big difference, but it could mean the difference between winning a new project or losing it to someone else — which is exactly what happened to me recently.
A few weeks ago, I was informed by a prospective client that they had decided to work with another provider. Whenever this happens, I am gracious and thank the client for considering us in the first place. I also ask them what the deciding factor was. In this case, they loved our proposal and solutions, but another company had given a detailed demonstration of their preferred CMS and showed how they would use it to keep the website up to date. That company showed them instead of told them.
I’d be lying if I said I didn’t kick myself upon hearing this feedback. I would have been happy to give this client a CMS demonstration, but they didn’t ask, so I didn’t offer. Instead, I answered their questions — all the while thinking I was giving them what they wanted.
Certain things are more effective when shown instead of told. (Image: Joe Penniston)
The other provider’s CMS is not necessarily easier to use than the one I was offering, but I never even made that case because I told the client how easy our solution was to use, instead of showing them.
Lesson learned: Talk is cheap. Regardless of whether the client specifically asks for a demonstration in your proposal, showing them goes a long way by backing up your words.
Staffing changes are a reality in this industry. Team members move onto other positions and opportunities, but business must go on. Projects need to be finished, and websites and clients need to be supported. As one team member departs and another joins, you will establish a plan for existing projects and clients, assigning responsibilities and tasks as needed. Still, however solid and measured your plans may be, don’t neglect to inform your clients of these staffing changes.
I learned this lesson when a longtime colleague recently left for another position. We had a plan in place for the transition, a plan that involved him working with us part time to continue handling certain clients and services. The impact on our clients would be minimal, and I decided that we didn’t need to inform them of the changes because the services we provided would not suffer and the change in our staff would likely go unfelt. I was wrong.
It didn’t take long for one of our clients to reach out to my departing colleague. My colleague’s work emails were now being forwarded to me, so I received the client’s request. We made the changes requested, and when I emailed the client to notify them that the work was done, I also explained the change in staffing to account for why the response was coming from me. As you can probably guess, they were surprised by this news, and what should have been a non-issue suddenly became an issue, simply because the client hadn’t learned of this sooner and was taken by surprise.
While some staffing changes are certainly not appropriate to discuss with clients, others really do affect clients in a pretty big way. A person may be the client of a company as a whole, but if their day-to-day interaction is with a particular team member, then that team member “becomes” the company in their eyes. If that team member ever decides to leave, the client could feel as though they are switching providers, even though the company is still more or less the same.
So, be proactive in informing clients of staffing changes. By explaining your plan for the transition of responsibilities with their account and reassuring them of your continued support of their company, you show them that, despite the change in staffing, you are still thinking about them and their needs.
Speaking of transitions, another reality in this industry is that clients sometimes decide to move onto another provider. When this happens, there is a period of transition away from your services, and you will likely need to be involved in that transition. This can be a strange and uncomfortable time, in part because you’re concerned about money.
Ongoing clients have an incentive to pay their invoices because they want to continue working with you. Clients who switch providers are worrying because of the possibility that they won’t honor any outstanding invoices — including time spent helping them transition away from your services.
This situation is delicate and needs to be handled case by case. Their reason for leaving, their overall payment history, how much they currently owe you (if anything), and how involved you will need to be during the transition are all factors that will determine how you handle the situation. The big lesson I have learned, however, is that dwelling on exactly when you will get paid during this time of transition, which is often a time of uncertainty and even fear for the client, is rarely wise.
When I’ve focused on payment and gotten aggressive in making sure the client understands their financial obligation to us, those clients have actually turned out to be less likely to settle their accounts in good time than clients whom I approach more softly.
Providing outstanding service to a client during a time of transition is the best way to end a relationship. If the relationship ends on a positive note, then the client will be more likely to pay what they owe and to say nice things about your company, because the last impression you’ve left them with was helpful and positive.
Again, how you handle such situations will vary. If the breakup is messy, or you are owed a substantial amount of money or lawyers have to get involved, then you would handle that transition differently than if you had a good client who was leaving simply because you were no longer a good fit.
For more tips on handling client payment issues, see “Dealing With Clients Who Refuse to Pay.”
When we make decisions on a project, we often look for relevant data to justify our decisions. Referring to website analytics and usage data can help us make informed decisions, but remember that all of this data refers to the past, not the future.
The Web industry is constantly moving forward, and if we make our decisions based solely on data gleaned from past usage, then the solutions we develop will be perfectly suited to those past situations, not necessarily future ones. This happened to me about a year ago when we were working with a client to come up with a mobile strategy for their website. While we absolutely wanted to make the website responsive, the scope of the project and the budget simply did not allow it. Plans were made and a budget allocated to redesign the website the following year, and a fully responsive design would certainly be part of that project, but for now, a separate mobile-only website would be our short-term solution.
As with many mobile websites, our plan was to include only a small, targeted subset of the enormous content archive found on the current website. Looking back now, it was a mistake. Unfortunately, content parity wasn’t an option, so to determine what content to include, we looked to the analytics to see which pages mobile users were accessing. Office locations and directions, leadership team biographies, and contact details were the most popular pages being requested by mobile users, so that was what we included on the mobile website. There was, however, a problem with this logic of including only currently popular content on the mobile website: It did not account for future needs.
As we were working on the mobile website, the client began to focus on their blog. They formed a team of authors among the subject matter experts in their organization and began publishing a lot of quality content — content that quickly became popular with their audience. This new blog content was often promoted and shared via social media, and many visitors accessed those links via mobile devices.
You can probably see where this is heading. Because we had no data to show that the blog would be popular on mobile devices, we left the blog off of the mobile website. When the blog picked up steam and attracted interest from users on social networks and mobile devices, the website we had developed became a major problem. The experience would be as follows:
Obviously, this experience was exceedingly poor, and very few visitors went through the entire process just to read the article. Most just left when presented with the mobile home page, instead of the article they were hoping to see. Even though we knew from the start that this mobile-only website was temporary, had we more effectively planned ahead and not based our decisions solely on analytics from the past, we may have been able to avoid this problem and develop a better solution.
In this case, the answer was to kick off the responsive redesign project sooner and do away with this separate mobile-only website and its subset of content. The lesson we learned is that we have to look to both the past and the future when making decisions on a project.
Making new mistakes helps you learn new lessons. (Image: Elyce Feliz)
This is why clients hire us in the first place — not only for our execution, but for our expertise. This expertise includes knowing where the industry is headed, what principles have to become an integral part of the experience (content parity) and what new technologies or approaches we can bring to a website today to ensure that it works well tomorrow.
All of the blunders covered in this article are ones I’ve made that either took a project off track or strained a relationship or made a product far less successful than it could have been. As soon as I realized each mistake, I wished I could jump back in time and have a do-over.
Well, I’ve yet to find that elusive time machine, but I do get do-overs of sorts. Every time I encounter a similar situation, I am able to make a better decision as a result of having learned the lesson from the previous mistake. That is my do-over, and that is the value of learning from one’s mistakes.
We all make mistakes. (Image: opensource.com)
What mistakes have you made, and what lessons have you learned from them? Not many folks like to talk about their mistakes, disappointments and things that just didn’t work out, but quite often they’re just as useful as all those amazing success stories you can read about in hundreds of books and articles. What tools worked for you and which didn’t, and why? Please share your stories and your thoughts with us by using the hashtag #smworkflow!
(al)
© Jeremy Girard for Smashing Magazine, 2013.
]]>