Freelancers, you have learned to never start work without a written contract, but it’s hard to like contracts. They’re impossible to read, long and boring and you just can’t wait to sign that piece of paper to get it done and get to the real work. Well this post is here to help.

(Image Source: Fotolia)

Contracts are pretty important in a designer’s career, and despite your apprehensions with legal documents, it’s worth getting into some specific details that can make a huge difference in practice. On a legal standpoint, these are rights that every freelance designer should try not to give away by waiver or assignment.

This won’t always be possible, but remember that every "no" you get from a client can be used as leverage to convince them to pay more for your design work. Here’s what you should look out for.

1. Portfolio Display Rights & Moral Rights

Portfolio rights are simply the permission to display the work in your portfolio after it’s done. Few clients have a problem in granting you this (as long as it is for personal use) but if you’re under a work-for-hire contract, these rights are not automatically granted. In fact, you may need to ask them if you want to add screenshots of your work or reproductions to your own website.

Portfolio display rights usually drag in another set of rights called "moral rights". Moral rights include the right of attribution, the right to have a work published under a pseudonym or anonymously, and the right to integrity of the work. It doesn’t feel great to have your design completely destroyed by someone else after you handed it over, particularly if your name is attached to it.

Sell Your Work, Not Your Rights To It

The legal implications of moral rights are pretty complicated, also because they change greatly from state to state. In most European countries, they are inalienable, i.e. you can’t sell them away in a contract. On the other hand, in the US, a waiver of moral rights is pretty standard for any commissioned work.

As a creative professional, you want to keep these right as much as possible, so always look if there’s a clause that asks you to waive them, and try to have it removed, or at least mitigate its scope, like in this example clause from an Illustration Agreement.

“Artist’s Right to Authorship Credit. Artist may use Work in Artist’s portfolio (including, but not limited to, any website that displays Artist’s works). Commissioner and Artist agree that when asked, Commissioner must properly identify Artist as the creator of Work. Commissioner does not have a proactive duty to display Artist’s name together with Work, but Commissioner may not seek to mislead others that Work was created by anyone other than Artist.”

2. Rights To Unused Sketches

Graphic designers, this is for you in particular! So you created a bunch of logo ideas, or a number of characters and different images to help the client choose. It is likely that even if that client doesn’t like them, they are good ideas that can be used elsewhere in your work.

(Image Source: Markus Kaiser)

Ensure that you can "recycle" your sketches and unused designs with a specific provision that allows you to keep full ownership of unused drafts. For example:

Client requests Designer to create [description of the work]. Work includes only the final, deliverable art, and not any preliminary Work or sketches.

Give Permission, Not Your Rights

Developers can do something similar with a "design tools" clause. Do you have any snippets of code or fonts that you incorporate into multiple projects? These are your tools. Just because they are in some client’s project doesn’t mean that the client owns the tools.

Instead, you give the client permission to continue using the tools, like in this example:

"Designer Tools. The Designer may incorporate certain Designer Tools into the Deliverables. "Designer Tools" means all design tools developed or utilized by Designer in performing the Services, including without limitation: pre-existing and newly developed software, Web authoring tools, type fonts, and application tools. In the event Designer Tools are incorporated into any Final Deliverable, then Designer grants Client a royalty-free, perpetual, worldwide, non-exclusive license to use the Designer Tools to the extent necessary to use the Final Deliverables. Designer retains all other rights in the Designer Tools."

The Safety Net

In some instances, you might want to tackle the opposite problem: what if someone sees your sketches in the proposal and just decides to copy the idea without hiring you? If this is something you fear, just add a notice of confidentiality to any proposal you send.

3. The right to walk away

If things start to go the wrong way halfway through the project, there comes the urge to drop the project and cut losses. Whoa… not that fast. Once you have signed a contract, you’re legally bound to finish the project and deliver what is promised. This is particularly bad if you are working on a fixed fee, as any estimation error in pricing the project can ring up time and financial losses.

(Image Source: Fotolia)

Last Resort Exit Strategy

While a kill fee usually takes care of things on the client’s side, it’s up to you to prepare an emergency parachute for yourself, the service provider. Try to add in the option to terminate the agreement, with reasonable notice, like in this Consulting Agreement:

"Termination. Either party may terminate the contract at any time through written request. The Company shall upon termination pay Consultant all unpaid amounts due for Services completed prior to notice of termination."

4. The Right To Solve Disputes Near You

This right is usually granted by law to consumers. Consumers are usually the weak party when litigating with a big company, and having to go litigate in another state is very expensive. That’s why for example, consumers from the European Union can always sue in their local district court.

With design agreements, however, you’re on your own; so have a look at the jurisdiction clause before signing a contract. If your client is in the same city as you are, there’s no issue, but if your client is in some other place, they probably want things to follow their jurisdiction and law. This is far from standard.

It is always worth negotiating this part, and a good compromise is suggesting some place neutral, that at least won’t give an unfair advantage to one party or the other. You can also consider options like online mediation and arbitration: always a great idea that will save everybody a bunch of money if things go south.

Editor’s note: This article is contributed by Veronica Picciafuoco. Veronica is the Director of Content for Docracy.com, the home for free, open source legal documents. She has a legal background and works closely with tech startups and freelance designers in Brooklyn, NY. You can find her on Twitter, Linkedin and Tumblr.

Disclaimer: This article wants to be useful and informational, but should not be treated as legal advice. All legal documents cited are only to be used as a starting point. The author, Hongkiat.com, Docracy and the original authors of the documents cited disclaim any liability connected to the use of these material without a licensed attorney.

Related posts:

1. 8 Contract Clauses You Should Never Freelance Without
2. Roadmap to Freelancing: Getting the Deal (Part 2)
3. Useful Tips and Guidelines to Freelance Writing
4. Popular (but bad) Freelancing Advice You Should Ignore

There are a number of CSS Preprocessor, LESS, Sass, Stylus, and Swith CSS, just to name a few. CSS Preprocessor, as we have said often before, is primarily intended to make authoring CSS more dynamic, organized and productive. But, the question is, which of them does the job best?

Well, of course, we wouldn’t be taking a look at every one of them, instead, we will only compare two of the more popular ones: Sass and LESS. To decide, we will compare the two in seven factors: the one that performs better gets one point; in the event of a tie, both will be awarded one point.

Let’s begin.

Installation

Let’s start with the very fundamental step, Installation. Both Sass and LESS are built upon different platform, Sass is running on Ruby while LESS is a JavaScript library (which it was actually also built on Ruby at first).

Sass: Sass needs Ruby in order to work, in Mac this has been pre-installed, but in Windows you probably need to get it installed before you can start playing with Sass. Furthermore, Sass needs to be installed through the Terminal or Command Prompt. There are several GUI applications you can use in place but they are not free.

Read also: Getting Started with Syntactically Awesome Stylesheets

LESS: LESS is built upon JavaScript, so intalling LESS is as easy as linking JavaScript library to your HTML document. There are also a few GUI applications to help in compiling LESS to CSS and most of them are free and performing very well (e.g. WinLess and LESS.app).

Conclusion: LESS is clearly in the lead.

Score so far: Sass (0) – LESS (1)

Extensions

Both Sass and LESS have extensions for faster and easier web development.

Sass: In our last post, we had discussed about Compass, the current and popular Sass-based extension. Compass has a number of Mixins to write CSS3 syntax in less time.

But Compass is beyond just CSS3 Mixins, it has added other very useful features such as Helpers, Layout, Typography, Grid Layout and even Sprite Images. It also has config.rb file where we can control the CSS output and some other preferences. So, in short, Compass is an all-in-one package to do web development with Sass.

LESS: LESS also has several extensions, but unlike Compass that has all we need in one place, they are separated and each of them are built by different developers. This won’t be a problem for seasoned users but for those who are just starting out with LESS, they need to take some time to choose the right extensions that suit their workflow.

Here are a few LESS extensions that you might need to include in your project:

• CSS3 Mixins: LESS Elements, Preboot, LESS Mixins.
• Grid: 960.gs, Frameless, Semantic.gs
• Layout: Even.less
• Misc: Twitter Bootstrap

Conclusion: I think we have to agree Sass and Compass is a great duo and the Sprite image feature is really kickass, so one point for Sass here.

Score so far: Sass (1) – LESS (1)

Languages

Every CSS Preprocessor has their own language and they are mostly common. For example, both Sass and LESS has Variables, but there is no significant difference in it, except Sass defines variables with a $ sign while LESS does it with an @ sign. They still do the same thing: store a constant value.

Below, we will examine some of the most commonly used languages both in Sass and LESS (based on my experience).

Nesting

Nesting rule is good practice to avoid writing selectors repeatedly and both Sass and LESS have the same fashion in nesting rules;

Sass/Scss and LESS

  nav {  	margin: 50px auto 0;  	width: 788px;  	height: 45px;  	ul {  		padding: 0;  		margin: 0;  	}  }  

But Sass/Scss takes this method a step further by allowing us to also nest individual properties, here is an example:

  nav {  	margin: 50px auto 0;  	width: 788px;  	height: 45px;  	ul {  		padding: 0;  		margin: 0;  	}  border: {      style: solid;      left: {        width: 4px;        color: #333333;      }      right: {        width: 2px;        color: #000000;      }   }  }  

This code will generate the following output.

  nav {    margin: 50px auto 0;    width: 788px;    height: 45px;    border-style: solid;    border-left-width: 4px;    border-left-color: #333333;    border-right-width: 2px;    border-right-color: #000000;  }  nav ul {    padding: 0;    margin: 0;  }    

Conclusion: Nesting individual properties is a nice addition and is considered best practice, especially if we follow the DRY (Don’t Repeat Yourself) principle. So, I think it is clear which one is doing better in this case.

Score so far: Sass (2) – LESS (1)

Mixins and Selector Inheritance

Mixins in Sass and LESS are defined a bit differently. In Sass we use the@mixin directive while in LESS we define it with class selector. Here is an example:

Sass/Scss

  @mixin border-radius ($values) {  	border-radius: $values;  }  nav {  	margin: 50px auto 0;  	width: 788px;  	height: 45px;  	@include border-radius(10px);  }  

LESS

  .border(@radius) {  	border-radius: @radius;  }  nav {  	margin: 50px auto 0;  	width: 788px;  	height: 45px;  	.border(10px);  }  

Mixins, in Sass and LESS, is used to include properties from one ruleset to another ruleset. In Sass, this method is taken further with Selector Inheritance. The concept is identical, but instead of copying the whole properties, Sass will extend or group selectors that have the same properties and values using the @extend directive.

Take a look at this example below:

  .circle {  	border: 1px solid #ccc;  	border-radius: 50px;  	overflow: hidden;  }  .avatar {  	@extend .circle;  }  

This code will result as;

  .circle, .avatar {    border: 1px solid #ccc;    border-radius: 50px;    overflow: hidden;  }  

Recommended Reading: Selector Inheritance the Easy Way: Introducing @extend

Conclusion: Sass is one step ahead by distinct Mixins and Selectors Inheritance.

Score so far: Sass (3) – LESS (1)

Operations

Both Sass and LESS can do basic math operations, but sometimes they return different results. See how they perform this random calculation:

Sass/Scss

  $margin: 10px;  div {  	margin: $margin - 10%; /* Syntax error: Incompatible units: '%' and 'px' */  }  

LESS

  @margin: 10px;    div {  	margin: @margin - 10%; /* = 0px */  }  

Conclusion: Sass, in this case, is doing it more accurately; as the % and px is not equivalent, it should return an error. Although, I actually hope that it can be something like 10px – 10% = 9px.

Score so far: Sass (4) – LESS (1)

Error Notifications

Error notification is important to see what we are doing wrong. Imagine thousands of lines of code and a tiny bit of error somewhere in the chaos. A clear error notification will be the best way to figure out the problem quickly.

Sass: In this example, I’m just using Command Prompt to run the compiler. Sass will generate an error notification whenever there is invalidity in the code. In this case we will remove one semicolon on line 6, and this should turn to an error. Take a look at the screenshot below.

When I first saw this notification, I could hardly understand it. Also, it seems Sass is slightly off with where the error is. It said that the error is on line 7, instead of 6.

LESS: With the same error scenario, LESS notification is more well-presented and it also appears to be more accurate. Take a look at this screenshot:

Conclusion: LESS delivers better experience on this matter, and wins hands down.

Score: Sass (4) – LESS (2)

Documentation

Documentation is very crucial part for every product; even seasoned developers would find it difficult to do things without Documentation.

Sass: If we take a look the documentation over at the official site, I, personally, feel like I am in the middle of a library, the documentation is very comprehensive. Yet, the look and feel, if that matters to you, is not motivational for reading, plus the background is plain white.

The presentation is much more like W3 documentation or WikiPedia. I don’t know if this is the standard of displaying documentation in the Internet, but it’s not the only way.

LESS: On the other hand, LESS documentation is clearer without too many text explanations, and it dives straight into the examples. It is also has good typography and a better color scheme. I think this was why LESS attracted my attention in the first place and I can learn it faster because of the layout and presentation of the documentation.

Conclusion: The LESS documentation presentation is better, although Sass has more comprehensive documentation, so I think we can call this one a tie.

Score so far: Sass (5) – LESS (3).

Final Thought

I think it’s a clear conclusion that Sass is better with a total score of 5 versus 3 for LESS. However, it doesn’t mean that LESS is bad; they just need to be better. In the end, it is still up to the end-user’s decision to pick the preprocessor of their choice. Be it Sass or LESS, as long as they are comfortable and more productive, then that is the winner in their list.

Lastly, if you have something in mind about this subject, feel free to share it in the comment box below.

Related posts:

1. Syntactically Awesome Stylesheets: Using Compass in Sass
2. Getting Started with Sass: Installation and the Basics
3. LESS CSS Tutorial: Designing A Slick Menu Navigation bar
4. LESS CSS – Beginner’s Guide

Ever run an online background check on a new employee you are at the verge of hiring or someone you met whom you are interested in? What happens when something unsavory turns up? Will this influence your decisions in both cases? If it might, chances are that the bad things that are written about you or your company online may turn away potential suitors as well.

Bad reviews or a negative piece about you are written in spite – someone already doesn’t like you and would like to spread and continue the trend for as long as possible. This can have a rather damaging effect, but only if you don’t know how to deal with it.

According to this infographic by InventHelp, these bad reviews cannot be delete but can be drowned out by real positive reviews by professionals. Take a look at how this can be done.

Read also: More Infographic related posts.

Spot an infographic you think will be a perfect fit here? Send the link to us with relevant details and we’ll credit you with the find.

Related posts:

1. The Battle for Bandwidth [Infographic]
2. Online Shoppers: Why Online Reviews Can Save Your Day
3. Evolution of Apple Products (2001-2011) [Infographic]
4. International Internet Scam Hotspots [Infographic]