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

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

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

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

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

Since I began this group, the scope of what it means to be a front-end developer has dramatically changed. There are so many more tools in our arsenal and there is equally as much confusion.

Adding to this confusion is the growing number of front-end frameworks that have the goal in mind to make our lives easier, but fail in their delivery.

Throwing technology and frameworks at the problems are not solving any of them. What's missing from the solutions are the discussion and community involvement needed to come to conclusions that address the problems that front-end developers deal with on a daily basis.

Truth is, discussions and involvement are hard. Reaching for some off-the-shelf software that solves all your issues is easy. Thus the rise of Bootstrap. The design API for front-end development. For those who don't know, they LOVE IT. For those who do know, this is the worst tool possible.

Zurb's Foundation and Bourbon's Bitters are good starts, but not everyone solves problems these ways. We need soluti

anotheruiguy

Life is ever changing, right? Everything around us is always in a constant state of change. You learn early either to be flexible with these winds or you resist them.

Evangelizing beyond the Rails developer

Back in 2008 I heard about this thing called Rails and a fellow developer told me about a new CSS language called 'Sass'. At the time I was working for a company that heavily leveraged Microsoft technologies and Ruby was not something that we could plug into our environment. Sass was a ncoew toy I could read about, that's as far as it went.

Fast forward just a year, I moved on and began working with a Rails team. Their first question, "You know Sass?" I said, "Nope, but it's a great time to learn!"

Since then I have been a huge advocate for the use of Sass and still continue to promote awareness. Within the Rails community, this is pretty easy to evangelize, moving away from Rails, even today it is difficult to convince people. I went on various speaking engagements, and spoke about better ways t

anotheruiguy

There are a lot of great articles out there on how to set up Sublime text and all the reasons behind those choices. This is NOT one of those :)

Here is a quick list of things that are really popular with Sublime users.

Link Bash to Sublime

On the Mac - run this command in Terminal

anotheruiguy

And my article is deprecated!

As of just writing this, Express 4.0 was released and there are points in there that no longer matter. So, this remains as a great >4.0 article.

Node.js is the red-hot new hotness! You can't throw a stick on the internet without hitting someone talking about Node. But why? For one, it's built on JavaScript which is completely ubiquitous. So, why not build a development stack and server on JavaScript? I would argue that the installation is almost painless while the terseness of the language is not.

While you can create apps 100% from Node.js, the Express framework is a great tool that helps you solve many standard problems without having to write boilerplate code.

Node.js is here and it's not going anywhere anytime soon. So if you are new to Node.js, Express, and even JavaScript in general, this is a great newb's step-by-step guide to get started.

anotheruiguy

For the question of setting the state of 'invalid' when building interactive web apps, there are two options. Using the class of .is-invalid is an easy and common option, but semantically worthless.

HTML5 uses the pseudo element of :invalid, while this is better because we don't need to program against this, the fail is that everything is invalid until the user interacts with it when coupled with the attribute of required as shown in this example gist. There is also a JSBin version you can see too that is better for viewing on a device.

9942957

While I am comfortable with the common use case of the class of .is-invalid for the presentation of the state, I also advocate for adding all the appropriately semantic attributes.

In the end, for an invalid state we could end up with an <input> element like the following: