noelietrex

[noelietrex]

HOW TO: turn .mov into a gif

Using Adobe After Effects + Adobe Photoshop (CC 2015)

1. Open your .mov file in AE.

2. Create a “New Composition” with the dimensions you’d like your gif and change the frame rate to be lower for smaller gif size (I usually stick to 12 FPS).

3. Drag and drop the movie onto the composition. Then select the movie and use shortcut ALT + COMMAND + F to fit the movie to the composition. Or select the movie and got to “Layer” > “Transform” > “Fit to Comp”.

4. Now add the file to your render queue by going to “File” > “Export” > “Add to Render Queue”.

5. In the render queue, check your “Render Settings” and make sure you’re using the 12 FPS or whatever frame rate you’ve chosen instead of the default video frame rate. Also check your “Output Module” and select “Audio Output Off”.

6. Hit “Render”.

7. Open PS and go to “File” > “Import” > “Video Frames to Layers...”

8. Choose your .mov file and adjust the toggles to clip your video to the portion you want to use for your GIF. Keep in mind GIFs are usually very short clips and that the longer your selection, the larger your files size will be.

9. On the slide timeline select a frame rate. I usually use 0.08, but adjust this to what feels right. (Select the first frame and press the spacebar to toggle play/pause animation.)

10. To save the GIF go to “File” > “Export” > “Save for Web (Legacy)”.

11. Choose the GIF setting that fit within your size limitations. For most applications I’ve encountered GIF size is limited to 3 or 5 MB. It’s common to sacrifice video quality to meet these limitations.

12. Choose your looping options. For this instance, and most that I come across, the GIF will loop “forever”. And hit save.

I hope this tutorial was helpful! Enjoy and share!

[noelietrex]

Ads: A World Without Flash

We’re officially in transition and it’s time to let go of Flash and move on with our lives. If you’re looking around the web right now, you’ll notice a lot of static ads unsure of how to proceed, new HTML5 ads trying to figure it out, and a few people still clinging to the past with flash ads literally frozen in time.

Chrome and Safari are now officially freezing all flash content and requiring users to click to play (aka no one is watching). Analytics aren’t reporting on how many people are actually watching flash ads because having the content loaded on the page is counted as an impression wether or not viewers choose to play the ad. With Apple devices like iPhones and iPads never having supported flash content, and now major browsers halting flash video, the nails are in the coffin. It’s time to say goodbye to flash.

So now what?

The short answer is “We’re gonna use HTML5 y’all!"

This video from Google’s Double Click is a great place to get started:

https://www.doubleclickbygoogle.com/articles/how-build-html5-ads-step-step-workshop/

The reality is that everyone is experiencing growing pains at the moment. Some people are still running their old flash ad campaigns with much lower viewership. You’ll see a lot of static ads running while designers and developers try to navigate the new HTML5 options. And those who are on the ball are already using HTML5 ads with varying degrees of success due to several factors: CSS animations aren’t as smooth as flash, there are new file size limitations that aren’t globally set at the moment, there are bugs integrating Green Sock JS animation library currently, and google has a new Google Web Designer tool to help create more custom ads quickly which is available but is still in Beta.

What can you do as a designer or developer while all of this is going on?

Get ahead of the curve! Jump on the HTML5 bandwagon ASAP and start pumping out HTML5 ads. Poke around in Ae, Adobe After Effects, to edit your video, keeping in mind that shorter is better (5-7 seconds, 10 seconds max). Then integrate HTML and CSS into your ads taking advantage of CSS animations to keep ads interesting and interactive. Don’t code? No problem- download and check out Google Web Designer, link below. Keep an eye out for news and information, and keep changing your process to meet the new standards.

RESOURCES

Google Web Designer: https://www.google.com/webdesigner/

IAB HTML5 for Digital Advertising 1.0: Guidance for Ad Designers and Creative Technologists: http://www.iab.net/html5

Build Guidelines from DoubleClick: https://support.google.com/richmedia/answer/2672542?hl=en

How to Build Responsive Banner Ads with HTML5: http://hub.bannerflow.com/h/i/127726733-how-to-build-responsive-banner-ads-with-html5

[noelietrex]

I know you’ve heard about how important responsive web sites are to reach the growing percentage of your audience browsing the web via smart phones and mobile devices. Emails are currently trying to make the same transition with more users than ever checking email from their phones and tablets. Unfortunately responsive emails are more complicated than websites and follow a different set of rules.

The complication with responsive emails is primarily due to the wide range in email client support. For example iPhone’s apple mail supports media queries (which makes responsiveness infinitely easier to achieve) although none of the other clients support this. Gmail supports using background images while Outlook does not. Yahoo mail supports using max-width while Outlook does not. The list goes on and on. If you’ve noticed that some of the emails you receive on your phone look better than others, this is probably why.

Here are 3 simple, straightforward tips that help you optimize your content for mobile user readability (even if your emails aren’t fully responsive):

1. Simplify Your Images - While an image with lots of overlaid text and tons great detail might be an awesome desktop experience, it probably isn’t legible when it shrinks down to fit a mobile viewport. Instead of trying to fit all of the text content into the email image, try simplifying the image with perhaps one large main headline of text overlaying it. Then include the text details below the image so it will be accessible to both mobile and desktop users.

2. Limit Your Design - Complicated, multi-column layouts aren’t good for mobile users. The idea is to create the best user experience for the largest number of people. With email clients so inconsistently breaking down multiple columns of content, you’re better off with clean, simple, single-column layouts. This way desktop, and as many mobile users as possible, will have a consistently good experience.

3. Keep Your Text Clear and Concise - While this is good advice for all emails, it’s especially important for mobile viewers who often swipe through emails quickly while on the go. Approach email text with a clear mission (Get a user to click through to sales for example). Break out your call-to-action headlines so that they’re clear and support your main mission. If you do find your supporting text getting lengthy, consider breaking up the content into two or more emails. A series of related emails with small, digestible content is more effective than one large, overarching email that’s oversaturated with content.

Mobile users are looking for a clear message, a simple layout that will do well across different platforms, and images that maintain their integrity at any size. Keep these in mind and you’re well on your way to great user experience for both mobile and desktop viewers.

[noelietrex]

How To Start Learning Javascript for Free!

If you’re a front-end developer like me who started out writing only HTML and CSS, using JS for functionality only through plugins, you’re probably as intimidated by JS as I was. No worries though! In my experience, the best way to learn JS is to just start trying to make something real work.

Check Out Free Courses

There are plenty of free courses available out there, and it’s a good idea to start by getting acquainted with concepts and semantics. I think starting with jQuery is the path of least resistance to developing functional, useful JS so I’m including jQuery tutorials here as well:

https://www.codeschool.com/courses/javascript-road-trip-part-1 https://www.codeschool.com/courses/try-jquery http://www.codecademy.com http://code.tutsplus.com/courses/30-days-to-learn-jquery

Tinker + Fiddle

While these courses are fantastic and may be an end-all be-all for some, I never got very far with actually being able to write anything useful until I was thrown into the deep end. My next recommendation is to start making something, anything! Reinvent the wheel here. Don’t follow along with a tutorial. Pick something you want to make work, and pursue it. Create a basic image slider, make some buttons that drop down ‘more info’ text, make a news ticker. There are loads of playgrounds online where you can write code and see your updates instantly. These are my favorites:

https://jsfiddle.net http://codepen.io http://liveweave.com http://stackoverflow.com (when you sign in and go to post a question there is an icon you can push to include a working snippet, basically the same as jsfiddle)

Reference It

Make your mistakes, write terrible code, google the shit out of ‘how to do X,Y, Z javascript’, use your references, ask stack overflow questions (for best results include a jsfiddle example of your code), and keep going! The usual suspects for referencing:

http://www.w3schools.com/js/ https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference https://api.jquery.com http://jqfundamentals.com

Get Involved

Finally, become an active member of the community. Put your code on github, look at other developer’s code on github, comment, ask questions, repeat. Start a code pen account, look at other dev’s code pens for inspiration and useful snippets. Follow other coders on social media and check out what they’re talking about and what projects they’re working on. See something cool? View page source, inspect, google! Learn something from other people’s code, and start writing your own regardless of how bad or simple or duplicative it may be at first. The more you write, the more you’ll understand, and the faster your skills will improve.

[noelietrex]

5 Awesome Blogs for Interactive Design + Development 2015

For all of those people walking the line between design and development, this is for you! Below is a list of my 5 favorite blogs so far this year, whether they are design or dev heavy, and why they’re awesome. Enjoy :)

ONE.

http://tympanus.net/codrops/

DESIGN or *DEVELOPMENT*

WHY I LOVE THEM: Their playground has awesome, simple JS and CSS demos and tutorials. Great for components or to base an entire website around.

TWO.

http://justcreative.com/

*DESIGN* or DEVELOPMENT

WHY I LOVE THEM: This is a very well-rounded blog. It has the usual free icons, resource bundles, and industry expertise, but also includes outliers like how to offset the desk job lifestyle, how to improve your face-to-face networking, and how to have more fun with web design.

THREE.

http://alistapart.com/blog

*DESIGN* or *DEVELOPMENT*

WHY I LOVE THEM: This blog is very much into theory and the philosophy of web design and development. They’ll discuss latest trends, cover pros and cons for specific web design and development schools of thought, and talk at length about UX/UI. While they do offer the occasional round-up of well-groomed resources, you won’t find much fluff content like freebies and favorites.

FOUR.

http://designmodo.com/

*DESIGN* or DEVELOPMENT

WHY I LOVE THEM: While I list this one as design heavy, they do offer some insight into development. The thing that really sets them apart is a focus on UX. If interactive is your space, you’re definitely going to want to check these guys out.

FIVE.

https://ihatetomatoes.net/blog/

DESIGN or *DEVELOPMENT*

WHY I LOVE THEM: This blog is actually a one-man show, but he works hard to collect great front-end specific resources and create original front-end content. He’s also right on trend at the moment with some great posts about using SVGs.

[noelietrex]

What the hell is a Github?

A beginners guide to understanding and getting started with Github

Like me you may have stumbled into the development community by chance and out of necessity. You may have started smashing together websites with the most crude, basic understanding of HTML and CSS, slowly testing the waters with jQuery plugins and ultra simple PHP forms. That’s totally normal and understandable! We all started there. Everyone who knows how to dev anything once looked at code like it was some kind of illegible alien inscription on the screen. So when someone says “just fork it from git” or “cool, send me your repo” or “do you git?” you may be thinking, oh no one more thing I don’t know how to do yet… But don’t worry! I am here to give you the fast and easy working-knowledge run down.

What is Github? (in a nutshell)

Github is a code sharing publishing service and also a sort of social networking site for programmers. It is a place where programmers of all levels and ability can create free accounts and put their code. Github stores the code, and when the programmer updates that code Github keeps a copy and a history of all of the changes. Every time you check in your code, it’s like a video game check point. You can continue forward with new versions or go back to that checkpoint to get your old code and try again when things don’t work out. Github backs up your work each time to check it in. Also Github is generally public so your code is available to share with anyone from your Github, and likewise you can see, download, and work on other people’s code. For this reason Github is often used by groups of programmers for collaboration purposes.

BASIC TERMINOLOGY

REPO A repository, or repo for short, is like a project or folder. It can contain one project or can act as a folder for multiple sub-projects that are all related. When you’re going to work on something new, you generally create a new repo for it. For example you might create a new repo called “CoffeeHouse Website” where you store the HTML, CSS, and JS that is used in your CoffeeHouse Website. If you work for a company they might have a repository that all employees share access to called “All Client Websites” where they keep the HTML, CSS, and JS in sub-folders for all of the websites they collectively maintain.

FORKING Github is all about version control. Joe makes a repo with version 1 of his cool website slider. You look at his repo and think you can improve his slider. You can then “fork” from Joe’s repo into yours and make your improvements. A fork is when you duplicate someones repo onto your own account. You can then change their code however you want and use it for your own project, or like in our example you can suggest improvements to what they’re doing. You then say “hey Joe, do you like the changes I made? I call it Joe’s website slider version 2!”

BRANCHING If forking is copying the whole repo over for you to work on it, branching is when you’re working within the original repo and you want to make changes to specific files. Branching happens most often when there are many developers working in the same repo. It helps to stop people from overwriting each other’s code and losing work. Branching is also how we work on versions without disturbing the original code. It can be a way of forking within your own repo. Your branch is a copy of your master or main code. You make changes and try some things. If you don’t like the changes and want to throw them away you delete your branch and your original code is unharmed. If your changes worked out great, you now want to replace your original code with the new and improved version!

MERGING Merging is how you take that new and improved version and make it officially part of your master code. You add (or MERGE) it in, overwriting the older version. Once we’re done making changes to a branch and we want to keep those changes as the new version of our code, we merge the branch into master. Or if we are talking about a whole repo, we can merge in a forked version of our repo, overwriting our current repo with new changes, and creating the newest version of that repo.

CONFLICTS Conflicts arise when we are trying to merge in some code that has changes directly conflicting with other changes made in the master code. In a team conflicts can be avoided by having everyone branch so that no one is working directly in the master code, but rather everyone is creating branches and then merging them back in. Conflicts do arise though, even on the most careful teams, and when that happens Github will try to put the files together the best it can with notes like this <<<<<<< HEAD >>>>>>> upstream/unmergeable-branch surrounding the conflicting code. Then someone will generally have to sort out the code behind and decide what to keep and what to throw away.

side joke

A group of geese is called a gaggle.

A group of crows is called a murder.

What do you call a group of developers?

A merge conflict!

PULL Pulling is when you pull code down from a repo. This applies when a team is working on the same files. Someone else may have added new code that you will want to pull to make sure you have the newest versions before you begin working.

PUSH Pushing is what you do when you are finished working on some code. You will push your code to the repo so that your team members can pull it, keeping everyone up to date with the latest version of that code.

How do I start using Github?

There are several different ways to access Github. The first is go to github.com. If you really wanted to you could use Github solely through their website. This is going to be the first step for anyone though. Go to github.com, sign up for an account with your email, create a username, add a picture of yourself for fun, and boom! You’re on Github. Congratulations!

Now is a good time to create a repo. You can create repos through the website easily. Just go to repositories and press the new button. You’ll name your repository and give it a description. You can choose to add some code to this repo right away, or just leave it blank with an empty readme (provided by default). And that’s it- you have a Github and a repository! Even those of us who regularly use github will sometimes set up a quick and easy repo this way to save a few lines of code for later.

Once you’re ready to start using Github regularly, you’ll want to either use a GUI (pronounced gooey, stands for graphical user interface) or learn to use the command line. If you’re interested in a GUI here is a comprohensive list as provided by git http://git-scm.com/downloads/guis. Using the command line in the terminal is somewhat more advanced and you’ll probably want to learn about the terminal in general before attempting to take a stab at it. Here are some resources for getting started with that: Do the first level of github with code school for free https://www.codeschool.com/courses/try-git, Git’s own step-by-step http://git-scm.com/book/en/v2/Getting-Started-The-Command-Line, and a more extensive guide if you’re into reading https://18f.gsa.gov/2015/03/03/how-to-use-github-and-the-terminal-a-guide/.

I hope this short explanation has been helpful enough to get you to a place where you can hold your own in a conversation about Github, and possibly to even get you online and setting up your first repo. Github is a very extensive, robust tool and I have just barely grazed the surface here. I highly recommend getting comfortable with the basics and then going your own research and exploration online into the more extensive features. You don’t have to know everything to get started, and becoming an expert absolutely starts with a first step. So GIT yourself in there- you can do it!

[noelietrex]

5 Reasons I Believe in Sketching as Part of the Creative Process

Sketching as a part of the design, and even development process, is extremely beneficial. It was suggested to me recently that this is a somewhat old fashioned idea, but I don’t think anything will ever replace pencil and paper for me. It’s my personal belief that you should never trust a designer who doesn’t sketch, and I’ll tell you why.

1. RAPID FIRE

Going directly form having a idea to putting that idea into the computer is skipping so much of the process work. The time it takes to design 50 logo variations on paper is so much less than designing 50 logo variations in the computer. I’m tempted to believe that going directly from the idea stage to the computer yields significantly fewer variations ever being explored. I would also argue that fewer variations and less process work means a lesser end product for the vast majority of us.

2. EXPLORATION

Exploration with shapes and color and combining ideas also happens a lot more quickly and easily on paper. Rather than creating another iteration in the computer, on paper we can easily redraw lines, splash the page with some markers to check out different color options, or quickly redraw the whole sketch including or excluding different elements.

3. FINALITY

The first idea we have is almost never our best idea. When we put our first idea into the computer we’ve likely invested enough time getting it in there that we’re now attached to it. Sketches are a great way to put every idea out there without becoming overly attached to anything. Throwing away 5 minutes of sketch time is a lot less painful than throwing away say half an hour of screen time.

4. PERSONAL TOUCHES

There’s nothing I dislike more than a logo without the personal touch. You know the one, it uses an unmodified, recognizable font and a pre-made star or swoosh with a gradient or common color scheme. Anyone anywhere can recreate it because it’s just a typeface and a shape and color. Where’s the kerning? Where’s the illustrative icon? Where’s the customization? A lot of these personal touches come out of sketching. When you bring an idea from paper into the computer, it’s often missing a little something that gave it soul on the page. That’s where you’re going to want to add your personal touch and customization.

5. FUNCTIONALITY

Plan out how it’s going to work! I don’t care if it’s a brochure or an app or a website. Draw out how the pieces and parts are going to interact; this is your blueprint. You wouldn’t build a house without a blueprint. Trust me when I say it is going to save time and effort all around, and get things done right the first time. You may find that you need to talk to the printer about folds or that you need to go over functionality with development or that your navigation doesn’t make sense after all and needs to be redone. These are great problems to solve and trouble shoot on paper before the major time and effort is put in with the computer.

For these reasons and more, I believe in sketching. Also who doesn’t love a fresh sketchbook and their favorite pen? There’s too much soul in the process work. There’s too much value in the journey. I know its tempting and you may think you’re saving time, but you’re missing out on invaluable information when you skip the sketching step. So get out there and scribble out your next big idea!

[noelietrex]

3 Simple Tips for Better Responsive Emails

I know you’ve heard about how important responsive web sites are to reach the growing percentage of your audience browsing the web via smart phones and mobile devices. Emails are currently trying to make the same transition with more users than ever checking email from their phones and tablets. Unfortunately responsive emails are more complicated than websites and follow a different set of rules.

The complication with responsive emails is primarily due to the wide range in email client support. For example iPhone’s apple mail supports media queries (which makes responsiveness infinitely easier to achieve) although none of the other clients support this. Gmail supports using background images while Outlook does not. Yahoo mail supports using max-width while Outlook does not. The list goes on and on.

If you’ve noticed that some of the emails you receive on your phone look better than others, this is probably why. The email service being used may support other email clients, but not the one you’re using. They may be compromising to make their emails as responsive as possible and get content to the end user, realizing that it won’t render the same for everyone.

All of this being said, here are some simple, straight-forward ways you can optimize your content for mobile users (even if your emails aren’t fully responsive):

Simplify your images - While an image with lots of text overlayed and tons great detail might be an awesome desktop experience, it probably isn’t legible when it shrinks down to fit a mobile viewport. Instead of trying to fit all of the text content into the email image, try simplifying the image with perhaps one large main headline of text overlaying it. Then include the text details below the image so it will be accessible to both mobile and desktop users.

Limit your design - Complicated, multi-column layouts aren’t good for mobile users. The idea is to create the best user experience for the largest number of people. With email clients so inconsistently breaking down multiple columns of content, you’re better off with clean, simple, single-column layouts. This way desktop, and as many mobile users as possible will have a consistently good experiences.

Keep your text clear and concise - While this is good advice for all emails, it’s especially important for mobile viewers who often swipe through emails quickly while on the go. Approach email text with a clear mission (get user to click through to sales for example). Break out your call to action headlines so that they’re clear and support your main mission. If you do find your supporting text getting lengthy, consider breaking up the content into two or more emails. A series of related emails with small, digestible content is more effective than one large, overarching email that’s oversaturated with content.

Mobile users are looking for a clear message, a simple layout that will do well across different platforms, and images that maintain their integrity at any size. Keep these in mind and you’re well on your way to great user experience for both mobile and desktop viewers.

[noelietrex]

So many people don’t treat their social media accounts like their personal brand, but in this day and age online appearance is important! Your social media presence is often the first impression you send out into the world.

Do you want potential employers seeing a blurry photo of you at someone’s wedding on Linkedin? When you’re trying to close a deal, do clients have a professional photo to reference on your website? If you’re trying to land a consulting gig, and I google you today, would I find a trustworthy professional?

I know what you’re thinking, professional head shots are expensive. Says who? Above is a portrait I took of my husband earlier today with our point-and-shoot digital camera. It’s lightyears ahead of his previous Linkedin picture- a blurry, cropped photo from Christmas (the last time he wore a suit).

So how’d we do it? A few simple tips for taking a social media worthy head shot from a totally amateur photographer:

DRESS UP The age-old cliche is totally appropriate here. Dress for the job you want. Stop hoping someone will snap a good shot of you the next time you’re dressed up at an event, and create the circumstances yourself. It might seem silly, but treat this like a real photo shoot and get yourself looking good.

LIGHTING The best and easiest light to work with is natural light. I don’t know about you, but I don’t own any box lights or reflectors. For a great head shot, find a space with a lot of windows and natural light and make sure your subject is facing toward it. We chose the lobby of our apartment building for this picture because it had great generic furniture and decor. For best results try at least 3 well-lit locations for variety. Coffee shops, book stores, hotel lobbies, or your own home near a large open window are all great places to start.

IT’S A NUMBERS GAME Take your time, vary your angles, change up the pose and props, and take as many photos as you can! You can’t expect magic in a handful of images, but that’s okay because you’re only looking for one or two viable ones. Again, treat this like a real photo shoot. Spend a couple hours at least and get lots of variety in.

I hope these antidotal tips help. In case anyone is wondering we shot this photo with a Pentax K-01 on auto. If you can borrow a nicer camera than you own, by all means go for it! If not, social media is no quality control freak, just grab the best thing you’ve got and get yourself looking like a professional! 

[noelietrex]

While we, the members of the development team, can definitely give some lip when it comes to making deadlines and struggling through Herculean dev tasks, this is not the kind of “Sass” I’m referencing. Sass has been instrumental lately in meeting the aforementioned deadlines, and moving these mountains of code. You could say Sass is the robust styling language that gives a front-end developer the strength of a hundred men (or women)! Sass, short for “Syntactically Awesome Stylesheets”, is a CSS preprocessor. The SCSS variation of it that we use most often on front-end is its simpler, more convenient application. Now, time to answer the question at hand: why is Sass/SCSS so “awesome”?

1. Learning is easy. If you can write CSS (cascading style sheets), you can write SCSS because any valid CSS translates to valid SCSS. Any new code can be added as you learn it. Know how to nest elements? Great! Write your usual CSS and nest those elements! Know how to define variables? Guess what, you can do that too. Define some variables (see #2 for an example) and start saving some time. No need to know everything to get started. You can use what you know now using SCSS, and as you continue to expand your knowledge base, you will be able to apply it.

2. Save time. I mentioned before that Sass saves time, but now we will dive into the best ways to do so. If you use the program to its fullest capabilities, the return will be greater, but even knowing the basics can completely change your workflow. Quite possibly the biggest timesaver is nesting elements to avoid repetitive code.

Instead of writing out:

header .left { color: green; } and then header .right { color: blue; }

You can nest by writing:

header { .left { color: green; } .right { color: blue; }}

Now your code is clear, concise, and intuitive. And, when specificity is necessary it can be applied effortlessly.

Another huge time saver is utilizing variables. For example, you can go from writing out hex codes like #028482 to writing $highlight. Then when your client is ready to change their brand colors from teal to navy, you can just swap the variable and voila, website updated! Of course, including mix-ins, breaking files into partials, taking advantage of operators, and using inheritance are also great for saving time, but they’re a little more advanced. (If you want to learn more, I included the below resources.)

3. Compile your way. SCSS is a preprocessor language, meaning the short-hand version of your styles will need to be compiled into traditional CSS for browsers to read. There are a lot of different options for compiling that can be easily integrated into your workflow. SCSS can be compiled using a compiler or the terminal. SCSS can also be compiled locally to output CSS, or as part of a more robust system where the CSS is pushed live and never seen. Sass can be compiled with everything from Grunt to Ruby to Sublime to compilers like LiveReload and Prepros, with new options added all the time. I recommend LiveReload compiler -- it is simple, straight-forward and great for beginners.

4. Tap into libraries. There are tons of frameworks and libraries full of grid systems, mix-ins, and styles just waiting to be tapped. These libraries are fantastic for getting a website up quickly, creating responsive sites intuitively, and ultimately keeping you from reinventing the wheel. Why debug the same cross-browser issues that someone else has already solved? A few of the more popular libraries and frameworks include: Bourbon, Neat, Susy, Saffron, Compass, Zengrids, Zocial and Sassy Buttons. If you have your heart set on doing things your way, you can always invent your own library or modify someone else’s to suit your needs.

5. Join the community. There are people all over the world using Sass to make their lives easier and they are talking about it! Look for blogs and forums – odds are that if you want to chat about it, other people already are. There’s a whole community sharing repos, fixing bugs on stack overflow, and blogging about their favorite tools. Follow Sass topic leaders on Twitter, subscribe to design and dev podcasts, get on a mailing list or two, and get yourselftuned into the Sass world.

So for all these reasons and more, we Sass. If you want to learn more, check out the beginner links below.

http://sass-lang.com

https://www.codeschool.com/courses/assembling-sass

http://sassmeister.com

http://thesassway.com

http://neat.bourbon.io