Rants & Raves

Musings on software, programming, design, and business.

There was a blog post years ago that was widely read and adopted on how to use EMs for font size. The TL;DR was that if you set the font size of body to 62.5% that makes the math for calculating and em font size easier. For example 12px would be 1.2em, the caveat here of course is that em is relative to it’s inherited font size and as such any font size declarations within that element would then be relative to 12px.



In the above code, the .bar class when inside the .foo class renders at 10px. Then can get confusing with heavy nesting, and of course you have to use *gasp* a calculator at times.

When REMs the value is always relative to the root font value on the html element.



This much easier to understand, and code for that matter. An added bonus is that now 1 rem is 10px all the time. This can be used for layouts purposes … heights, line-heights, padding etc… And the someone zooms with their browser, or is using some device that has a wonky zoom our layout stays in tact.

Lately I’ve seen a lot of examples of detailed and creative animations on the web using SVG paths. I did a little investigating and found some interesting tricks to achieve this effect.

First, we can start with any SVG file. I took our Bootsoft logo and converted it using Illustrator, but there are also a bunch of online tools that will take bitmap images like .pngs and convert them for you. Since SVG is an XML format, if you open your SVG file in a text editor it should look something like this:

We can drop this SVG markup directly into an HTML document to render it in a browser. This is supported in all modern browsers back to IE9.

Now we can use CSS style up the SVG paths a little bit. Normal CSS classes can be applied to SVG path nodes to target them specifically. We’ll give the paths that make up the logo’s spur a blue stroke color:

We’ll also need to add the spur class to our markup:

Now that we have our rendered SVG image looking good, we can work on animating its paths. We can do this using the javascript APIs for SVG and requestAnimationFrame (for IE9, you will need to use a requestAnimationFrame polyfill). To bring this all together we can write a simple JS constructor to setup our SVG elements accordingly. This code is largely inspired by Brian Suda’s SVG animation article. Let’s start with:

Most of this is boilerplate, but it’s important to note the two properties we’re setting on the SVG paths: style.strokeDasharray and style.strokeDashoffset. At this point, setting this offset makes the paths invisible. In order to animate the path, we will be incrementing the offset to give the illusion of a line being drawn. Let’s write a method for our constructor to make this happen:

Now we simply have to create an instance of our AnimatedSVG object and call .draw()

Check it in action here => http://jsfiddle.net/ez3rraex/

Additional notes:

  1. You might want to include the requestAnimationFrame shim, although I’m not entirely sure if it’s necessary anymore.
  2. You can modify the totalFrames property of the AnimatedSVG constructor (or parameterize it) to change the speed of the animation.

The languages of the browser, HTML, CSS, and JavaScript are berated, harped on, abused, misused, and contorted to do all sorts of things they weren’t designed to do.  HTML in it’s core is a semantic language intended to organize documents and the relationship between them.  CSS is simple, straightforward, but hardly dynamic.  Even with Less and Sass, the resulting output is a flat static stylesheet that was never meant to power rich interfaces.  JavaScript was designed in 10 days and as we all know is the most misunderstood language – thank you Papa Crockford. As someone who writes JavaScript day-in and day-out, I am fully aware of all the issues with it. However, the community is massive and the toolsets are plentiful. What was originally used to perform superfluous tasks is now a great option for a unified language application. Javascript is the only viable way – today – that we have to express a dynamic interface in a browser.

HTML5 has been a big step forward, but it does not really deliver in terms of fluid interfaces, particularly for mobile.  Older methods of DOM access and manipulation are flawed, and ripe with performance issues. Dealing with these issues is complex. Everyday development cycles should be abstracted from having to deal with limitations like these. Famo.us does this for us, and from what I’ve seen so far – it does it well.

Browsers have gotten really good.  Our desktop machines are crazy powerful.  Most of the time folks aren’t cognizant of any performance issues with the sites they browse on their desktop machines.  All of this often masks the limitations of HTML/CSS/JS, or poor implementation by the developer.  On mobile devices however, the cracks in HTML5 start to show.  Although smartphones and tablets today are indeed amazingly powerful for their size, the mobile browsers they tote are a far cry from their desktop cousins.  This is where it becomes quickly apparent that HTML5 is not as magical as we think it is – or have been told it is.  When Zuckerberg – of Facebook –  said “The biggest mistake we made as a company was betting too much on HTML5 as opposed to native” it was a huge blow to the perception of HTML5 in the mobile space.  Recently there have been rumblings of a Front End framework that is solely focused on providing a toolset to use HTML5 in a performant way.  This framework is Famo.us, and it wants badly for the web to win.

Famo.us is alot of things; a 3D layout tool, a physics engine, a native wrapper (yet to be seen), a MVC (yet to be seen), but more importantly it’s an attempt to solve the biggest rendering performance issues of HTML5.  Stabs to crack this nut in the past have fallen short in my opinion.  Sencha Touch is a very mature JS MVC with a rich UI kit, however it is beholden to a heavily nested DOM which will grind your app to a halt if you try to get too fancy.  Ionic framework is a more modern attempt to create a UI kit for mobile, and leverage AngularJS as the app convention.  Although the DOM is much lighter, it doesn’t address a fundamental issue of nested elements, reflows, repaints etc.

Famo.us recently entered a controlled beta – adding a few hundred accounts a day, and allowing access to early guides and documentation.  I am excited to be attending HTML5 Dev Conf for hands on Famo.us training and hackathon, and to be a part of this beta release.  What I have seen so far is very promising.  There are a few things that Famo.us is doing that will give a speed boost to the DOM by addressing how we structure and think about modern web apps.

The Flat DOM

Famo.us uses the concept of surfaces and modifiers for layout. Surfaces are what they sound like, a flat surface – In the DOM represented by a div node.  Surfaces are dumb, they don’t know where they are, they don’t know what size they are.  Modifiers are objects that hold, and can modify the state of a surface.  This can be opacity, x/y/z position, and a host of other properties. A surface’s associated modifiers control its properties, as well as any other surfaces that follow.  This abstraction between surface and modifier allows the developer to chain modifiers and surfaces together, which creates a representational render tree such that a modifier can affect many surfaces below it on the tree.  This concept is central to how one architects the layout.  The association of surfaces is held in the JavaScript code instead of in the markup.  This allows greater flexibility and expressiveness in the tree.   The result is a DOM of surfaces that are siblings, and we avoid the pesky nested DOM tree of yore.


There is a great article on HTML5 Rocks – A resource for open web HTML5 developers about CSS3 and hardware acceleration.  What is not mentioned in that article the the transform matrix3D – which allows a 16 digit matrix of values to describe a point in space in a 3D perspective along with rotation, skew, and scale.  Famo.us wraps this property up and uses it as the main driver of it’s layout engine – flipping brilliant if you ask me.  This allows them to run operations against multiple matrices of modifiers for super performant, complex transitions.  Deeper under the hood Famo.us leverages the JS method “requestAnimationFrame” to know when to update the matrix – ensuring users perveice the UI at 60fps.

Sticky DOM

Nothing really groundbreaking here I would say.  Caching reference dom objects is one of the first things listed in any best practices guide for DOM speed.   Many frameworks have optimized themselves around reducing DOM touches.  They all have their own special flavor on how they get that done, but the concept is straightforward.  I like to think of JS and the DOM as being on opposite sides of a river.  There is a bridge and, as with all bridges, there is a bridge troll.  Everytime the bridge is crossed in order for JS to talk to the DOM, the troll blocks your path and charges a speed tax.  Famo.us’s modifier / surface separation allows the developer to care less about accessing the surface, since the modifier is where all the slick transitioning is handled.

The performance problems that Famo.us is attempting to address, along with the rich catalog of physics, animations, and other features included make it a framework to definitely keep an eye on moving forward. Bootsoft is committed to the open web, and are looking to leverage any piece technology that helps us move that goal forward.  When Famo.us is ready for prime time, we will happily find the right project to unleash it on.

I had the pleasure of attending An Event Apart in Boston back in April. Self-described as, “The design conference for people who make websites”, it was definitely a huge inspiration and learning experience for someone who does, indeed, make websites. The conference consisted of twelve speakers from all walks of the web world. Over the course of two full and informative days, I learned so much about the future of web design and technology. There were a wide range of topics that were touched upon, but I want to focus on what I felt were three underlying themes: responsive design, screen sizes, and user experience. Now, these may not come as a surprise from a web conference, but of course there are new and interesting ways to discuss and think about these topics.As much as I’d like to separate these three topics into sections, I can’t! Due to the fact that they are so relevant each other, I must discuss them through the ideas and guiding principals expressed at an An Event Apart.

One of the big focuses was creativity. There is so much that can be done with the web, and people shouldn’t feel restricted to standards. Don’t be afraid to push forward new ideas just because they’re different from what everyone else does. We have gotten very wrapped up in the PC paradigm where everything is organized by pages, but in reality, the current orientation of various devices has rendered the page fold moot. Jeremy Keith provided an example of the password field, and how the standard is to hide the text and show those all too familiar bullets or asterisks. This was developed as a standard because people has this idea that someone might be standing behind you watching you as you type. Future has shown this to not really be the case. Now, in a world of decreasing screen sizes, keyboards are less tactile and much smaller, so the ability to see what you are typing is pretty integral. It can get very frustrating trying to type a long, complicated password (which is the requirement from many sites nowadays) where you cannot read what you’re typing. A trend that is catching on is having the option to show or hide the password.

Screen Shot 2014-05-30 at 3.17.57 PMScreen Shot 2014-05-30 at 3.18.07 PM

Instead of deciding for the user, give them the option. Just because everyone has been doing the same thing for years, does not mean it’s the perfect solution, especially when we live in a world of ever changing technology.
There are also so great ways to embrace new technology even if it isn’t supported. The beauty of the browser is that it will ignore code it doesn’t understand, so there is no reason to not implement new things and be ahead of the curb instead of playing catch-up when the trend is already established. Some cool ideas that I found particularly interesting were from Luke Wroblewski and Lea Verou. Luke discusses the already familiar media queries and how to use them in more innovative ways, for example, using a vertical media query. Why not consider the fact that people are using so many different screens and that maybe certain screen orientations should consider where the call to action buttons are, or how large the font is. Consider the user and how they are interacting with their screen. Lea Verou talks about color for the web and how to make it more usable for the programmer. From hex codes to rgb, there hasn’t really been an intuitive way of coding color. If someone gets familiar with the convoluted formula, sure they would easily be able to identify a color by hex or rgb., but why should it have to be learned? If someone has any semblance of constructed color, be it from painting or just choosing color schemes, they should be able to figure out how to code color without having to use multiple programs to identify a scheme and figure out hex or rgb. Lea introduces the HSL variant. Using hue, saturation and lightness to determine a color. This form of color thinking is so much more intuitive and logical. I’m glad that this idea has been taken into consideration and pushed forward. Programmers are users too, and there is no reason we shouldn’t be given the opportunity for a good user experience within code.

Screen Shot 2014-05-30 at 3.13.30 PM
© Luke Wroblewski 2014

Screen Shot 2014-05-30 at 3.11.53 PM
© Lea Verou 2014

Another way to really respect and focus on the user is using research. Investigate the types of people coming to your website, or your competitors’. There are plenty of resources for this kind of research to be done easily. (Chartbeat, etc) the beauty of this method is that there is no longer an excuse for uninformed decisions. The idea that opinions are left up to taste and personal preference becomes irrelevant, and good design and functionality can shine through with research supporting it.

In 2011, a study done by equation research found that 71% of people expect their phones to load almost as fast, if not faster on their phone than their desktop (Source). For many who work in the web, this just seems absurd because it’s a pretty standard fact that of course things load slower on a phone. The truth is, people who are not keeping up with technology in the way that we are, are bound to expect different things. People expect because its smaller it should move faster, or because its a more intimate interaction that it would be faster. The beauty of user research is that we are able to find out users’ beliefs, things that we may not have realized because we forget how involved and informed we are about technology. Another study shows that 90% of user are finishing tasks across multiple devices and screens (Source). This is a really interesting and important fact to know! This makes the understanding and focus on multiple screen experiences so integral to design and development.

We can get very wrapped up in the massive amount of screens that are now on the market, and worrying about how to accommodate all of them. We need to keep focus on the fact that the user is who we are designing for. Continuing to focus on the user will help us move away from us relying on devices, to the devices using us. Think of the actual physicality of using a device; it doesn’t get much more intimate than interacting with your hands. It has always seemed natural to move from using buttons to everything being done on touch screens. If we consider the posture of the user, if they may be laying down or sitting, or standing while using a device, it can really educate us on how to properly design the functionality. Creating accessibility across all devices can include the support for both touch and mouse/stylus across devices. You shouldn’t automatically assume that a certain sized screen is going to be using touch. There are some more features to media queries as well – level 4 includes the ability to identify device orientation, the device’s aspect-ratio, the resolution of the screen you’re viewing, what kind of input is being used (touch or click), and my personal favorite… the light-level. I can see light-level being really neat to work with for color schemes, font sizes and other things. It will use the sensor on your phone (that will automagically change the screen brightness depending on how bright or dim the light is where you are) and you can then change various components depending on the level, whether its normal, dim or washed.

Media Queries Level 4 (Source)

@media (orientation:portrait) { … }

@media (device-aspect-ratio: 16/9) { … }
@media (device-aspect-ratio: 32/18) { … }
@media (device-aspect-ratio: 1280/720) { … }
@media (device-aspect-ratio: 2560/1440) { … }

@media (resolution >= 2dppx)
@media print and (min-resolution: 300dpi)

@media (pointer:coarse)
@media (hover)

@media (light-level: normal)
@media (light-level: dim)
@media (light-level: washed)

All of these considerations of the user can really help drive forward good design and development. Instead of focusing just on the devices and how to accommodate for them, we need to make sure the user is the priority. Another way to ensure a great experience is to allocate time to make sure your page load speed is up to par. Just comparing yourself versus competitors and sites that are well made is a great way to gauge how much work needs to be done. There are some great tools you can use such as ChartBeat (Link), WebPageTest.org (Link), and Page Speed Insights by Google Developers (Link). One way or another these sites can really help you find valuable information about your users and how easily they are able to interact with your site.

I think one way I can sum up my learning experience is a pretty obvious statement, but I believe it’s worth repeating:


They are the bread and butter of why we make websites… and don’t forget, YOU are a user too!

After attending An Event Apart, I can certainly say I walked out of there with a ton of knowledge in my head and a skip in my step, ready to get to work on making more innovative and beautiful websites.
Thanks for reading!

The face of front-end development is in a constant state of flux. Web applications are becoming increasingly front-end driven, and the concept of a single page web-app powered entirely by REST-ful web services is the new norm. While libraries like jQuery have dominated the landscape for many years, they no longer provide all of the necessary tools for today’s client-side development world. The result is a major push from the front-end community for more robust tools and frameworks that make up for these deficiencies, one of the most popular of these is AngularJS.  Where jQuery is a toolbelt, Angular is framing, plumbing, and electrical.

Angular isn’t the only solution. Backbone is another popular framework that creates separation in the MVC pattern. It is, in my opinion, the most “bare metal” javascript MVC available in the open-source world. Although it provides some syntactic sugar for wiring events to elements with the scope of a view, it does not offer “two-way” data binding in the way that Angular does.  That is, if you assign a model to a views configuration, the frameworks leaves the work of listening to the model to update the view when data is changed. Building dynamic web applications takes a lot of code, and developers are forced to work with low level tools for DOM manipulation. Starting any new project involves writing a lot of boilerplate code to listen for user input, and then linking all of these listeners to some functionality.

Angular addresses boilerplate bloat code with a more graceful document life-cycle, then allows you to access this functionality through additional HTML attributes/tags/class known as directives. All of the functionality you would have to add using Backbone is moved behind the scenes. The philosophy behind Angular is that web applications are living documents that should update in real time. Creating dynamic client-side applications should not be such a messy endeavor.

The big win with Angular is two-way data binding. In a traditional web app, when a page renders it takes data, merges it with a templating system and then displays that data to the user.  At that point the rendered page is essentially static. Developers have to manually wire events for clicks, hovers, keystrokes etc, that update a data model or collection of models based on those events. The page then has to re-render the page using the template and updated data model.

In Angular, the View and the Model are connected by two-way data binding. Changes that happen in the View immediately affect the Model, and changes in the Model instantaneously change the View. More importantly, Angular sets up all of this functionality under the hood, so coding can be as simple as change a few HTML attributes and calling the template without writing a single line of JavaScript.

Two way binding is a huge timesaver, and also helps the developer think more in terms of the state of the app – which leads to a more consistent experience for the user.  Angular is massively robust and contains many other tools that allow for rapid development.  Dependency injection, custom directives, services, factories, and host of other nuts and bolts place Angular squarely in contention for the go-to JS framework.  I should also note that Angular is a product of our friends at Google, and so we may have a relatively high level of confidence in it’s progression and ongoing maintenance.

Bootsoft is always trying to find ways to contribute to the community, and one of our favorite ways is using our skills to give back! Over the weekend of November 1st-3rd, we had another GiveBack NY event (formerly named Create-a-thon). Since our last event in April 2013, we’ve partnered up with GiveBack DC, rebranded, and made another website for another well-deserving non-profit.

The group we worked with this time was Sports2Success. They use sports as a platform to empower today’s youth to help them pursue employment and become contributing members to the workforce. Through Sports Leadership Training and Apprenticeship programs, they build up kids with the confidence to excel in life, and through a career.

Working with Jamaal King, the Founder of Sports2Success, we were able to gather all the information and content for the website to get going. By creating wireframes prior to the event, it helps us plan a swift course of action for designing, coding and testing over the weekend. One of the challenges we faced, was the fact that there weren’t any photos of the group yet, so, Jamaal had an idea of creating a dynamic animation for the home page to help show what the organization is about. He sent us an idea for what it could be based on, and our designer Seung-Yun took it and ran with it! She was able to create the impressive animation that is on the home page using solely CSS and HTML. (You can view the site >>here<<)

The look-n-feel was created by myself, Kate B (the event coordinator for GBNY). I was inspired by S2S’s original logo, which was updated and simplified on the new site, and a theme of orange and dark grey/black used on their previous site. I wanted to add another accent color to the layout that wasn’t as bright as the orange color, and I felt that a pleasant teal-blue color complimented the orange and blended with the black and greys. I wanted the site to be engaging but simple, so a user could go to the site and quickly know where to go depending on what they wanted to do. I also wanted the site to have a fun and youthful look to it, seeing that it is a program for kids, but because the target audience is volunteers and supporters, I still wanted it to have a professional and organized feeling, as well.

Once I had the overall design ready to go, the developers were ready to jump in! We worked away all day on Saturday and got a ton of work done, to come in on Sunday to finish off the project and do some testing. For this project we used WordPress as a framework with Foundation and SASS. Everything went pretty smoothly, and we are so happy with the finished product!

Thank you to everyone who participated in this incredibly successful weekend, and can’t wait to begin planning our next event. If you or someone you know are involved with a non-profit in need of a website revamp – please apply at www.givebackny.org

The last time I wrote about Responsive Design was about a year and a half ago, and there have been so many updates and advancements. I wanted to take this opportunity to talk about how I’ve been using responsive design lately and what I’ve learned by doing so.

In my role as a User Experience Designer at Bootsoft, I get the privilege of seeing new projects move from inception, to design, to development. A big part of designing a site or application, is planning out the architecture. After meeting with the client and hashing out the product’s needs and functions, I do some sketches and conceptual wireframes. Through the wireframes, I am able to annotate and map out on a more general level how things are going to interact. After going through some iterations with the conceptual wire frames, we begin making a clickable prototype. The clickable prototype can be very helpful for showing the client how their product is going to work. Without having to worry about any of the back-end, we are able to show them a prototype that looks, feels and functions like they expect a website or an application to work.

For these prototypes, I have been using the responsive front-end framework, Foundation (http://foundation.zurb.com). I am a big fan of this tool, because it is easy to implement, it has a bunch of great add-ons for prototyping that make mocking up a website quick and easy (like modals, image sliders, etc).  It is also based on a grid, like the majority of responsive frameworks. The grid creates a layout that is controlled by percentages, so when changing the browser size, the content is flexible and logically rearranges itself.

One of the nice things about Foundation is that you can style it as much or as little as you like. Their core look and feel is actually very attractive – especially the buttons, forms and other added components. It’s clean and unobtrusive, which helps the client hone in on the core functionality of the user interface & experience instead of getting hung up on graphic elements.

We have used this framework for quite a few new projects, and so far it has been very successful both from my perspective and the clients. It is very intuitive and definitely makes my life easier when making clickable prototypes. What is nice about it is that when I need to make updates or changes, it’s incredibly easy and flexible to do so. As we move more into the Agile process, it is very important to work with technologies that are fluid and easy to work with, so for the wire framing and prototyping part of our project, Foundation has proved to be one of the best ways to keep with the rapid process.

I am really enjoying this method we’ve adopted for the discovery process, and I’m excited to keep moving forward with new and advancing technologies. It is so important to keep up-to-date with the direction of development and technology, and I am glad we’re are doing so, especially in this early part of a project. If you are trying to figure out a way to express specific functionality to a client, and flat wireframes just aren’t cutting it, I highly suggest using a rapid prototyping tool like Foundation!

Juan was recently the recipient of our monthly nailed it award.  The nail bestowed upon him is a nail from an old railroad tie.  If I were to imagine that our project was a train running on a loose track and seconds from disaster, Juan would be the guy I’d call.  I would say, “Juan! can you fix the track!?”  Juan would say “No problem, but first let me make some mate”.  He would calmly don a pair of aviator sunglasses, finish making his perfect cup of mate and stride over to the track as the train barreled around the corner.  Still holding the mate, he’d pound the nail in the railroad tie, securing the track and saving the day.  He would look at me over his aviators and recite the line from the movie, Dirty Harry, “You gotta ask yourself one question, Do I feel lucky?…well do ya punk?” to which I would reply, “yes I do!

We are certainly lucky to have Juan on the Bootsoft team.  Juan is consistently scrupulous in all of his work.  Everyone trusts any number of issues to be resolved with the speed and efficiency of a small bird making its nest before the winter.  And like a little nest, Juan’s work is always created with thoughtful precision and without defect.

Congratulations to Juan for nailing it!

I recently began to redesign my personal website which is just a place for me to show off all the different kinds of work I do (illustration, design, photography). I like to consider myself a pretty qualified front-end developer, so I am always interested in new practices and technologies.

I’ve been hearing and seeing the term “Responsive Design” everywhere. From the amount of screentime its getting all over the interwebs, its definitely only becoming more and more prominent. The reason it is so huge right now, is because everyone has a smart phone and tablets are on the rise. Everyone can get a google result or a webpage up in seconds with the little computer in their pocket or purse. The thing is, the layout of a phone’s screen is completely different from a computer screen, and people are viewing the web in so many different environments. What responsive design does is create a fluid transition between different site layouts, by determining what screen size the viewer is looking at.

So, instead of making three different websites, like one for a desktop, one for a tablet, and one for a phone, you make one website. Within the CSS, you just write different attributes for classes that will change and assign them to a specific screen size media query. Anything that is global, is written once in the global CSS and will apply to each layout.

For example, let’s say I want a different font size on the desktop version as I do for a mobile version. So, I’d go about my way for the desktop version, write the simple class like so:

.leftColumn {font-size: 12px;}

Cool, now on my computer’s browser the font is 12px. But on the phone I find that a little bit hard to read so I want to make it a bit bigger. I create a new section in my css and write this:

@media handheld, only screen and (max-width: 767px) {

.leftColumn {font-size: 14px;}


And voila! When it is detected that I’m viewing the site on a browser smaller than 767 pixels, it will change the font to 14px.

SIDE NOTE *** I should also note at this point, that a few of these attributes do not play nice with IE (surprise, surprise). This will like total doodie on IE6 (www.responsiveie6.com), and so far I’ve only tested in IE9 and 8. Looks pretty okay in 9 but 8 gets a little wonky. ***

A lot of the changing layouts rely on percentages and a columned grid. On my site, I have three columns for my content each at about 30% width (taking into consideration margins and padding). I also put a max-width on the columns, so if the screen is enormous, the layout is controlled.

I ended up using a template called the 1140 css grid (cssgrid.net) and it couldn’t have been easier. I often get completely intimidated by new coding styles and technology I’m unfamiliar with, so I was very hesitant to get immersed in this for fear of severe self-humiliation and potential pillow-punching… but it ended up feeling like I’d done it a million times before. This is why people should absolutely start implementing this. Its SO DARN EASY PEOPLE! This is coming from someone who didn’t really know what floats were and what they did until about a year ago. Just do it. There are so many templates out there (just google ‘Responsive web design template’).

This brings me to a topic that has also been popping up a lot, and that is the thinning line that divides designers and developers. There has been such a distinct separation in the past where its two completely different steps. The designer figures out the architecture of the site and then makes the pretty PSD files. Then those get handed off to the developer who just builds off of that psd. There is hardly any collaboration. With responsive design, the functionality and working parts  are now the designers’ concern, as is what the site will look like in three or more different ways is the developers concern. Both parties need to be conscious of the deliberate decisions the other is making.

I read an article recently that discussed working together and how important it is to involve the designer in the development process, and vice versa. I know from personal experience that sometimes some developers end up needing to create a new, minor functionality. Usually, they’ll just make it work and make their own decisions on how it should look because they think it is so minor, and then months later I just happen to see it and it looks terrible!!! (No offense devs… but its my job to pick out colors :) and emphasis on some.. some devs do know good design) and at that point, the project will be too far along to fix or change it. I’ve experienced handing off designs, and then feeling like I’m no longer a part of the project.

Especially with the current state of programming, its not all about being pixel perfect anymore. Its about making the site display correctly across many different browsers and operating systems. But, just because the designs are guidelines, doesn’t mean that the designer shouldn’t be questioned when there isn’t a deliberate design available to reference. A really important step is to assess any and all interactive functionality with the designer. I’ve seen a few hover effects appear out of nowhere after development that I did not design that way. Any page transitions, or changes in appearance, however slight the function may be, should be intentionally designed. One bad gradient, and the site can go from super classy to mismatched and funky.

So, designers, become besties with the developers and communicate with project managers that, yes, it is okay to come to me for a minor thing like a popup modal. And developers, you are amazing at what you do, thats why you do it, and same goes for me… I was hired to make the aesthetic decisions, but I want your input. Its hard to keep track of every little thing that should occur on a site, along with bajillions of potential use cases. So, its really important that if there is a certain function that was not designed, it should be just as important as every other designed element. This is all reliant on communication, and usually there is a middle man and/or woman, like a Project Manager, that needs to be a liaison between the two. If there is any uncertainty about something, everyone should discuss with each other to figure out the best course of action.

Viva responsive design!!

I would love to hear what you think about this… is responsive design the way to go? Do you actually think designers and devs should be separated in their work?

Writers’ Block. Everyone gets it whether they’re a writer or not. Its that part of your process where you hit a brick wall and your brain cannot process any new thoughts. I tend to get this when I’ve been staring at a design or wireframes for a few hours and my eyes start crossing. It usually hits in the afternoon, and sometimes just getting up to get a snack or glass of water remedies my predicament, but other times its a bit more serious.

All I need is some serious inspiration… and with the internet at my fingertips, its not hard to find some.

Designers (and non-designers!) can be influenced by so much. Everything in the world can somehow be interpreted into something creatively plausible by anyone with the ability to see. Color, light, movement, and shapes are everywhere, its impossible not to notice.

Here are some blogs and websites that I immediately go to to gain some creative input.


I always go here, even when I’m not stuck, just to check out the new stuff they’re doing. There are constantly new write-ups and demos with all the fancy new trends. I tend to do keyword searches like, typography or design and browse multiple articles within one theme to get in a certain mindset. Originally shown to me by Jeff Chew, I quickly became enamored with this group for their vast skill-set and wide arrange of knowledge across design, the web and usability.


I love coming to this site to clear my design hang-ups. This group of illustrators, designers, writers, photographers and thinkers compile a wonderfully simple, continuously scrolling blog. I find that their design aesthetics reference a lot of vintage and traditional graphic design, which is, appropriately, very graphic. The bold use of color with minimalist type is seen often, along with nostalgic photography and tons of patterns. This blog always brings me back to the basics and reminds me why I love to create.


ffffound is a great site that just has tons of images. What I love doing is scanning through until I see something that catches my eye, and then losing myself in an infinite cycle of clicking related images. There’s a lot of content on here, but with proper determination, you can find tons of inspirational posters, illustrations, designs and photos.


Clearly, the name is referencing ffffound, but this is a blog created by one guy who has a love for all things menswear, women and sleek design. Warning: There are nude images intermingled amongst so most definitely NSFW. He only posts occasionally but he posts so much its fairly easy to lose track of time scrolling through. This brings out the minimalist in me… his taste and aesthetic are beautifully simple.


Christopher David Ryan is a designer that I keep coming back to. He is incredibly talented with iconography and imagery. He invokes so much thought and feeling through his charismatically simple and joyful images. I usually keep up with his blog, but its always refreshing to just go back and look at his portfolio. A lot of his designs end up being my desktop!


Design Sponge is one of the most renowned design blogs out there, for good reason. Mostly directed towards interior design and decorating, Grace Bonney overflows her blog with tons of design-driven posts that are sure to inspire anybody. She has a ton of different writers from all walks of the earth that keep the content fresh and ever-changing. The DIY and Before-and-After posts are huge for getting you motivated to use your hands and get those creative juices flowing.


This is an invite only site, but once you’re in, it is incredibly addicting. You follow people who like the same kind of things you do, and the homepage pushes other users that are similar to you as well. This is honestly just a huge burst of inspiration… you can search any kind of keyword and just pour over images upon images.


Forrst is also an invite only site, but specifically for designers and developers. It is a social network directed towards those who design sites and those who code sites. They encourage critique, feedback and sharing your knowledge with others who ask. I spend a lot of time checking out other people’s designs and reading all the feedback to keep up with what audiences are seeing and feeling. Its like a virtual classroom, and its very rewarding for users who are active in the community.

At this point, I’ve probably lost you to at least one of the above websites, but I hope that if any readers are ever in a pickle, they can find solace and get revived from one of my suggestions.

Would love to hear other people’s suggestions for sites that spur creative thinking, so please share in the comments!