I went to school to study graphic design. More specifically, I went to school to study WEB design. It's interesting to me that most people do not understand this fundamental difference. The schools, at least in my experience, don't seem to really understand this distinction either. I spent a lot of class time worrying about layout for posters and pamphlets, agonizing over kerning and line spacing, and finding the highest resolution images possible, and very little time learning anything about web grid systems or CSS properties. Those things were fun and certainly useful but they don't translate to the web. Each medium has its own requirements and treating them the same is a mistake.
The things that are important and that you need to design for vary greatly based on where the design is going to be used. For print you will need those really nice, high-resolution images; you will have the time to agonize over the spacing on the third paragraph, and you will have the luxury of controlling the look of your rag for all of your type. As a web designer your concerns are different. Your images will have to look good on small screens and retina screen while also being served up quickly. While you can kinda set type on headers and, to a lesser extent, titles, body copy is fluid, it can look quite different depending on the screen it's viewed on.
Web Not Print
It is easy to think of the web as nothing more than an extension of print media, after all, most of the terminology comes directly from the print world. We read web pages, the copy is called copy, we have
section tags in HTML and properties such as
font-size in CSS. When HTML was conceived it was to give people the ability to share scholarly articles over a phone line, so it's no wonder that it has all of these print conventions.
The web, however, is not on paper.
Images need to scale to fit an infinite array of widths and resolutions. Columns need to appear and disappear. The space provided for copy of any kind depends solely on the length of that copy. On top of all of these moving pieces, we must add more moving pieces. The modern web resembles a body of water more than a piece of paper. It must fill the container that we put it in, while still maintaining its core properties.
As such when we, as designers, approach a web project we can't look at it as if it's a piece of paper. We confuse the edges of the artboards as the physical limitations of the design. I've seen designs where the 'hero' image goes all the way to the edge of the artboard and lines up with the vertical grid. A 'hero' image should take up the whole browser screen, a banner image takes up the width of the content container. So which one is it? Hard to tell on a lot of designs.
Fonts are another common pitfall for designers. HTML standards define only 7 sizes for fonts (
p,) but I've seen designs with 35! Sometimes with sizes set at fractions of a pixel. This is a side effect of designing websites in Photoshop or Sketch and then scaling the fonts till they 'look' right. Designing in this manner doesn't take into account the medium that the design is for.
Given how much convention is inherited from traditional print design, it comes as a surprise that understanding the medium and the framework is given so little importance on the web. This is so ingrained in print design that it is second nature, and the same needs to be true about web design. Without a thorough understanding of how the design will be built it is impossible to create a good design.
What On Earth Shall We Do!
OK, enough designer bashing - in reality I really like design and designers, really - and onto solutions. These problems have plagued the web since the days when Yahoo! was a new and exciting company, so you'd think that someone would have come up with something. Something like, oh I don't know, perhaps a comprehensive system that takes into account all of the limitations as well as the advantages of the medium. Something like a framework.
I'm going to go out on a limb here and say that most developers work very rarely in straight HTML/CSS/JS. They work with a content management system such as Drupal or Wordpress, or at the very least start their projects with Zurb Foundation or Bootstrap. I don't know anyone, personally, that has sat down and made a web page in plain HTML. At least not since leaving school. Furthermore, it makes little sense to do so. It's like a book printer building a new press every time he is producing a new book. There are tools, and we should take advantage of them.
We Can Make It Faster, Better
The primary advantage to using and, more importantly, understanding these frameworks is that things can be built quickly. There are a lot of moving pieces in modern sites. Navigation that changes based on the page you're on or device you're using; fun little animations, video, code embeds and whatever other things are going on behind the scenes like dynamic content and linking. Getting all the moving pieces working correctly takes time. Time which, unfortunately, most clients won't to pay for.
Building the structure is also incredibly repetitive. Just making those nice dropdown menus involves long lists of
<li> elements that are exactly the same. Using a framework allows us to not have to worry about setting 200 variables and adding in a browser reset. We can define a few global variables that vary from project to project, then move on to other things. Grid system? no problem! Just include a few pre-defined classes and all your columns have consistent spacing between them. Vertical typographical rhythm? Bam! Responsive images? Here you go! A good framework has all of this pre-defined so that you can go in and start on the important things like whether or not this is the right shade of cornflower blue.
To give an example, let us take a website with a nice looking topbar menu that has the logo in the middle as opposed to the left with links on either side. Since we are good little web citizens we'll also have to make it collapse on mobile into a 'hamburger' menu.
Looks really nice, right? Now how are we going to make it? The framework that I use most often is Drupal for the CMS and Zurb Foundation for layout. Foundation's menu doesn't use this structure so this means it has to be custom coded. Since we are using a CMS this isn't just a matter of creating it with plain HTML. It needs to include whatever links the client wants to put there. This wouldn’t be a big deal, I guess, if the client was willing to pay for 16 hours of extra time, but of course they won't. With good reason, that cuts into their profits. More than that, if - as a designer - you don't take that into account you will grossly underestimate the time and cost of building the site. Creating long days for the poor developers tasked with bringing your creation to life. Possibly leading to marital troubles for them when their wives ask why the must spend all night at the office. You don't want that on you conscience, do you?
There is a debate in the design community over designers learning to code. This is why they should. As a designer you don't need to create a website with a full LAMP stack but you do need to understand your medium enough that you can see where things will be difficult. If you don't understand the framework, you can't design for it. The web isn't going anywhere, in fact it's just getting crazier, so you need to design for it. Your developers (and their wives,) will like you more if you do.