Thoughts on my 2014

2014 has come to an end and it’s time to look ahead to 2015. 2014 was my first full year in a professional environment. I wrote my first jQuery plugin. This was also the year I really sunk my teeth into CSS preprocessors, automation, and version control to supplement my front end development.

Working for a full year doing web development has been a great experience. I used to think the hardest thing in programming was what to name your variables, but it turns out that – for me – it’s communicating your ideas. Because of this this, I want to blog more in 2015. I think it’ll help me understand my thoughts a little more. The ability to communicate technical ideas clearly to a non-technical audience is a skill I need to sharpen.

I dove into jQuery a little more thanks to videos by Paul Irish. This knowledge allowed me to write my first jQuery plugin. It’s nothing super amazing or technical, but it was a neat exercise in learning something new. Looking at example code of jQuery plugins made me feel uncomfortable at first, but as I stuck with it and kept reading, it started to gel together enough for me to write something that works.

This is the year I started using LESS as my CSS preprocessor of choice. I keep reading a lot about Sass, but haven’t tried it out yet because LESS does everything I need. LESS solves many problems I was tired of dealing with while writing plain CSS – namely lack of variables and mixins. The idea of compiling a few .LESS files into 1 CSS file seemed to make more organizational sense to me, so I never looked back.

Another addition to my workflow in 2014 was embracing front end tooling. I used to have no issue importing 9 non-minified .js files in the footer of a site. I used to FTP all my files manually every time they were updated. I used to download external libraries by just going to the library’s website, downloading the zip, then extracting it to my project. Now, I use grunt tasks to concatenate and minify my scripts and CSS. I use rsync to transfer my project to staging or production servers. I use bower to manage my site’s dependencies, allowing me to quickly download and update external libraries. These things used to seem advanced and scary to learn, but since I’ve gotten to know these tools, I can’t imagine working without them.

Finally, 2014 was the year I started using version control. Git tutorials and YouTube videos really helped me understand how important it is to a developer’s workflow, how it works, and how to use this powerful tool to manage your projects. Gone is the fear that something irreversible will happen to my project. I can rest assured knowing each version is backed up on my local repo and in the hosted repo (I like using BitBucket).

TL;DR – My workflow changed a lot for the better in 2014, and I got the chance to learn more about jQuery plugins (and as a side effect I now understand JavaScript and jQuery better). Looking forward to 2015, I hope to learn as much or more.

To Bootstrap, or not to Bootstrap?

Front end frameworks are great time savers for getting your project up and running quickly, but is the time you save setting up the project wasted when it comes to customizing the design?

At a conference earlier this year, I got the opportunity to meet Brad Frost, which was super awesome. I told him at the time I used Bootstrap in my front end development and he said something that got me thinking. He said that in his experience, front end frameworks (like Bootstrap, Foundation, etc) get you about 80% of the way, then you spend the last 20% fighting them while you customize it to not look like Bootstrap.

I could certainly relate to this. Where I work, there’s usually a designer on projects who drives what the website will look like. Very very often, the designer would come up with a very doable design, but it couldn’t be replicated in Bootstrap without heavy customization. I could get a quick prototype up, but it would take a considerable amount of customization before it was production ready in the eyes of the designer. By the time we were done, very little of Bootstrap’s styles were even visible, but they were still there in the code.

I saw this and it made me think about what Brad said. I was essentially using Bootstrap as a base, then customizing it so much that you couldn’t really tell it was Bootstrap. I might as well be writing it my way from the start, instead of hacking Bootstrap’s styles. So instead of hacking Bootstrap’s styles, I started compiling my own stylesheet only using the Bootstrap LESS files I need. Now, there is less of me fighting with Bootstrap and overriding styles. I only use their utility classes, vendor prefixes, grid, and scaffolding LESS files now and it gives me the quick start I want when doing a project, but allows for massive customizations without fighting against Bootstrap’s styles.

This is currently working pretty nicely for me. I could see myself in the future having my own grid system, mixins, etc that I take with my from project to project, but right now the Bootstrap ones are working great.

Walls Come Tumbling Down – Rethinking Workflow

Original Transcript

Worse still are the expectations that static visuals set in the minds of clients, particularly when designers use them as a method to get sign-off for a design. I often wonder, is the fact that so many web pages are fixed-width and centered, a direct result of clients signing off fixed-width design visuals?

I would even go so far and say that when you demonstrate a design as a static image, you are reinforcing a mistaken notion that a web page will be a facsimile of a frozen image. And when you demonstrate a design or ask for sign-off on a frozen image, you immediately leave yourself open to the problems that often come when you later implement that design.

We all know that it is impossible today for a design to render exactly the same in every browser or device.

You need only look at the different ways that Gecko and Webkit and Opera anti-alias text. The browser landscape is more diverse today than it ever has been before.

I know that many designers and developers understand that it’s neither practical, economical or desirable to attempt cross-browser pixel perfection, but what about the clients and managers that we work for? They still often subscribe to the outdated notion that you should strive for pixel perfection.

Get into the browser as soon as possible

I decided a little while ago that I would try and change my workflow. This has happened many times over the years. In 1998 when I was making Nintendo 64 websites, Notepad and a FTP client were major parts of my workflow. Since then, my tools and and process have changed a lot. I think one of the tenets of a good designer/developer is the ability to keep learning and recognizing when something in your process could be done better.

My new workflow is the result of a lot of reading and a lot of trial and error. I’ve come a long way from the days of Notepad and a FTP client.

Get in the browser!

This is something I would’ve been against in the past. I was still remembering the waterfall process where everything takes place in silos. The designer designs a layout, then passes it to a developer, who then pass it to the people who enter content. This method presents a lot of problems, mostly that the three phases happen in isolation. The graphic designer gets to make a lot of decisions without knowing if a) their design is even possible to implement and b) if the actual content would even fit into the design. If the developer and the content experts were involved in the design process, conversations could happen that would prevent issues like that.

Design, content, and development are all inherently intertwined. Design, content, and development need to happen somewhat simultaneously. As a developer, by getting right into the browser, I can work closely with designers to iterate on the design, get feedback, and enhance the interactive aspects of the site. I can also work with content experts who can provide me with some real world content to test in my prototypes.

Getting into the browser as soon as possible allows all three of these phases to happen simultaneously. Currently we’re trying something new. Instead of fully committing to a design in Illustrator or Photoshop, our designer roughs up some wireframe-y type stuff in Illustrator, and then I get that prototyped into something like Pattern Lab as soon as possible. Then lots of conversations happen. Content, design and development are all being considered at the same time now.

Tools like Slack make it easy to share links, screen shots, inspiration, and feedback with everyone on the team. Our Pattern Lab is at a public URL and is commonly referenced and discussed. So far this is leading to a lot of progress in a short period of time. Workflows within Pattern Lab could be a whole other post, but however you want to do it, get your styles broken down into atoms, molecules, organisms, etc. It makes prototyping so much more efficient.

Dave Olsen discusses this topic in detail in the video below and does a much better job than I discussing the problem and potential solutions.

Sharing what you know

While reading this wonderful article by Sibylle Weber about responsive design workflows, something rang really true for me.

We need to become experts. And I mean not just in writing great code or coming up with beautiful designs but at explaining why we’re doing what we’re doing. Why do you code this way or that? Why is this the best layout? Why does a website have to be accessible and responsive? Write about it. Putting your thoughts down on paper or screen is a really efficient way of getting your head around a topic and learning to make a case for something. You may even find that you come up with new ideas as you are writing, so you’ll become a better designer or developer along the way.
~Sibylle Weber

To write is to think. Writing is thinking. It helps us solidify our thoughts, focus our ideas, and become better at communicating with others.

This is something I’d like to work on with myself. The timing is perfect for me to be sharing what works and what doesn’t work in web development. At work, we’re currently undergoing a CMS transformation, as well as some other projects that are going to give me a first hand insight in what it means to progressively enhance and do some style guide driven development.

Share, share, share

In the world of web development there is a lot to keep track of. The only reason we’ve gotten so far with the web is because people keep sharing what they know. Then someone builds upon that and we have the next application framework. I’m going to make a solid effort to share what I know in the coming months.


Using only Bootstrap 3’s grid system using LESS

Import the following files into your main LESS file, replacing “../components/” with the appropriate path to where Bootstrap is located:

@import "../components/bootstrap/less/scaffolding.less";
@import "../components/bootstrap/less/variables.less";

@import "variables.less"; // Put your custom variables in here

@import "../components/bootstrap/less/mixins.less";
@import "../components/bootstrap/less/forms.less";

// Delete next 2 lines if you don't want the navbar styles
@import "../components/bootstrap/less/navs.less";
@import "../components/bootstrap/less/navbar.less";

@import "../components/bootstrap/less/grid.less";
@import "../components/bootstrap/less/utilities.less";
@import "../components/bootstrap/less/responsive-utilities.less";

// Import Font Awesome
@import "../components/font-awesome/less/font-awesome.less";
// Font path to be printed in CSS
@fa-font-path: "../src/components/font-awesome/fonts";

//Put custom files here
@import 'custom.less';
@import 'header.less';

That’s all you really need to get up and running with the Bootstrap grid system. The benefits to doing this are that your compiled CSS file will be super light-weight because you’re only taking in the parts that you need.