anotheruiguy

Hey everyone -

Just wanted to put this out there. Since I started thee first ever Sass Meetup in Seattle, it's been amazing watching others take the initiative in other cities.

In light of this, not to long ago I decided to offer up the @SassMeetup Twitter account to all other Meetups. Much like how UX Happy Hour does it, it's a great way for people to easily follow one account and be able to see everything that is happening in all the Sass communities.

I have published a list of all the Sass Meetups that I am aware of here:

It would be great for everyone to check this list out. Meetups are popping up all over the place, so if you are currently operating a Sass Meetup and are not on this list, I apologize. Please update the list with your information.

anotheruiguy

An aspiring UX developer recently contacted me and asked some interesting questions. The one that really got me was, "I'd love to hear more about your course (i.e. who is involved, what types of people attend and what were your original motivations for offering such materials?)"

What was my motivation? Why are there so few schools that offer this kind of course? Well, here is my response.

---

You sound like you are in the right track and learning some JavaScript will be beneficial for sure. More and more things will be going in that direction. jQuery is a good start, but be sure to spend some time learning the basics behind JS like ... what does it mean to be a loosely or dynamically typed language and what the hell is a prototype anyway? What is coercion and what it an object.

You make an interesting statement about JavaScript being a bridge between the front-end and back-end. What's interesting is that app engineers that were typically server side devs are now front-end devs because of JavaScri

anotheruiguy

Now that you know the basics of Sass, it's time to put these new skills to work in the best way possible. Learning the 'best practices' for writing Sass will gain you admiration among your peers.

This is a course I put together and working with the amazing team at Treehouse we created the Advanced Sass curse. If you have covered all the basics of Sass and are looking for more information on advanced topics, this is a great place to start. In this course I cover the following topics and much more:

• Getting started with architectural concepts.
• Digging deeper into Variables, Mixins, Functions, and Placeholders
• Color functions, random generators, strings and introspection
• Digging hard into Sass' directive library

So be sure to check out my Advanced Sass course and feel free to sign up for a free 14 day trial!

anotheruiguy

So I was presented with this interesting problem by a co-worker to come up with a CSS solution for a very common problem. Basically we are looking at a common layout for a list of items that will be placed into a grid with two columns. Simple, right?

Wrong. How do we do this? There are so many ways we can solve this problem that the solutions are a problem in itself. In this article I will walk through the process that I went through and how I came to a solution that I feel is pretty flexible and will carry us into the future of better layout solutions.

Rows and columns

A VERY common solution is to pretend this is a table and think of this as a series of rows and columns. I personally think that this is a very poor solution, why would we want to recreate tables for the sake of creating a table layout? For the sake of argument, I will walk through how this works.

anotheruiguy

tl:dr - the following is a long rant about the complexities of presentation layer development as it collides with the growing complexities of JavaScript front-end frameworks. This is a summary of my experiences, issues and proposed solutions to today's world of client-side application development.

Back in the old days (4 years ago)

It was a trend with the traditional model of app development that the app dev team would take a particular dominance over the presentation layer, as it was rightly so, their domain. The deign teams of the time resorted to non-code ways of communicating their intentions as to influence the design. The 'comp' and 'red-line' documents were the primary resource of communication. Practices that are not all that dead, people still do this stuff you know.

We all know by now that these processes don't really work. They are fraught with error and caused countless hours of frustration between designers and developers. Witness the rise of the 'designer - developer' or 'The Designer w