Designing In-Browser: A Manifesto
These are exciting times to be a web designer. CSS is finally starting to catch up to the visions of the beautiful websites we have in our heads. No longer do we have to rely on hacks and images to create wonderfully engaging interfaces! But we can’t just rely on browsers to usher in this new era. As creators we have to be flexible and adapt our workflow to encourage these new best practicees. It’s time to rethink how we make websites.
What I will be discussing today is not new or groundbreaking, but rather an extension of what you already may have suspected deep in the back of your mind for quite some time now. This article is going to serve as a counter-point to a lot of the other articles on this website that focus on Photoshop and Fireworks, but they are just the opinions of a single designer, so you can take them or leave them.
Meet Your New Design Tool
Our new blank canvas.
Rethinking Web Design Workflow
The new streamlined workflow.
If you’re anything like me, when you start a new website, you break out the sketchbook and start scribbling down ideas. You then open up Photoshop (or Fireworks) and hammer out the design. Code doesn’t even factor into it until the very last stage.
This is a fundamentally flawed idea, for many reasons. For one, a website is not an image. A finished website is a flexible, moving thing, built with HTML or CSS. Photoshop gives us (and our clients) unrealistic expectations for how a website will look and behave. You should be thinking about how the design will translate into code all the way through the design process.
Secondly, the whole concept of one “finished” design for a website is wrong. Building a Photoshop mockup and then saying “all right, now on to the code” gives a permanent feel to a web design, as if you were proofing a print before sending it off. One of the huge advantages of the internet is that it is ever-changing. Stamping a mockup as done says that this is the final version of the design that will exist. As designers, we should embrace the ever-changing nature of our medium and recognize that a design is never actually finished.
The advantage of designing with code is that you are forced to think about the content and the styles as two different things. The content will lead the design, rather than the other way around.
Obviously, you’ll need a browser. In fact, you should really have a few of browsers for testing. (Aside: I recommend Wine for IE testing on the Mac). At the very least you should have a Webkit-based browser like Safari or Chrome, as well as a Gecko-powered one like Firefox. If you’ve done any sort of web design before, you’ll doubtlessly have this area covered.
The web designer’s pyramid.
You should also have a decent code editor as well. Preferably something with a live-update feature like Espresso or Coda. I personally am a huge fan of TextMate, although it does not have a live-update mode. Again, as a web guy/gal you probably already have a favorite, but I might as well mention it for any newcomers.
Sketching is arguably the most important part of the design process. That shouldn’t change even if you design inside the browser.
You should still have a solid idea of what the design should look like before starting on the computer. At the end of the day, this is still design, and you should still use a sketchbook. I won’t go into detail about this part of the process, seeing as you, as a designer, should already be familiar with it. Just know that the same rules apply. You wouldn’t open Photoshop with no idea how your site will look, that would be crazy!
Actually, it doesn’t have to be sketching. Just do what works for you to create the concept. Whatever that may be, the important thing to consider is getting a solid idea in your mind before starting on the computer.
Image credit: Sean McGrath.
Layout is without a doubt the most important part of this process. You could have the most beautifully selected fonts, perfect colors, and delicious little details, but without a solid layout, the whole design will fall flat. Fortunately, building a solid, float-based layout with CSS is one of the easiest things you can do as a web designer. A List Apart has a Great Article on the subject that I highly recommend for the technical details of building a CSS-based layout.
If there’s one thing you should already know before going into your code editor, it’s the layout of your design. If you have a specific layout in mind, it’s a simple matter to code it up. However, if you go in without a layout in mind, I think you’ll be disappointed at the results. Layout isn’t a thing you can just experiment and switch out on the fly, it’s a matter that requires careful consideration on the designer’s part.
Even if you don’t know exactly where every element is going to live on the page, you should at least have a general idea of placement of main elements, as well as the proportions between those elements.
One of the great things about this new movement of “Responsive Web Design” is how it encourages designers to think in proportions, rather than pixels. For instance, you could say that this element needs to be 30% of the main container, as opposed to 200px or a similar measurement. This especially comes in handy for in-browser web design when one has to structure a page. You could start off with a main container element that is, say, 70% of the browser window, and then design the rest of the page inside that container in proportion to that element’s width. No more messing about with exact pixel measurements and that stupid Ruler Tool in Photoshop!
Image credit: Jennifer Chong.
At this point, you should all have at least heard of @font-face, even if you haven’t used it in a project yet. For all, i don’t know, one of you that hasn’t heard of it, here’s the one sentence version. @font-face is a way of embedding and using any typeface for use on a website, even if it is not installed on your users’ computers.
This simple idea has brought a whole new era of web typography in a matter of a few years. Entire businesses like Typekit and Fontdeck have cropped up for the sole purpose of serving up beautiful typefaces for your website. In the past we’ve been forced to rely on hacky methods like Cufon or just regular images to display our type how we want it, but all that is changing. Type foundry’s have largely embraced the new format, modifying their licenses to allow embedding, or even allowing their fonts to be hosted by Typekit.
So this is great, but what does it have to do with designing in-browser? Well, my good sir, I’ll tell you.
It’s a lot easier to manage typefaces when they are managed by CSS rules, not Photoshop...
Mucking about in Photoshop to change every single bit of text to a selected typeface becomes a little ridiculous after a while. In code, you can preview changes and test out different typefaces, weights, and sizes just by changing a few lines of text. This allows you to iterate your designs more quickly, and let’s you adapt a design for client requests with a few simple keystrokes.
All that power gets a little bit ridiculous when you consider that we now have an infinite number of typefaces to work with. As long as the foundries keep doing their thing, and Typekit keeps doing theirs, designers will never lack an appropriate font.
I highly recommend using Typekit, as many more fonts are available there than with a standard @font-face license. You can always manage the code yourself, but dealing with licences and having to purchase each font individually gets pretty ridiculous pretty fast. This is the option I’ve chosen on a few projects, and while it’s still infinitely better than what we had before, the experience wasn’t the best.
When it comes to chosing fonts, have fun with it! Experiment, try something crazy. If you’ll excuse the blatant self-promotion, I’d like to point you towards another article of mine.
In a “traditional” web design process, often the designer starts by constructing a grayscale mockup of their design in Photoshop, before adding the colors and details needed to make the design pop. This process is integral to the layout and overall feel of the design. Even if you don’t use black and white, constructing your design in sets of boxes and simple shapes really lets you see how your design will work from a higher perspective. The building of a design using simple boxes is really easily converted to our in-browser workflow. Just use <div>’s with basic CSS applied to them!
Once you have your layout and typography marked up and styled properly, introducing color becomes a trivial matter with a few lines of code. This isn’t to say that choosing the colors is an easy and simple technique (although there is a great article for that too), just that coloring the objects on a technical level is very simple. Even displaying beautiful gradients is easy with CSS3.
When I’m coding in color to a design, I often have Photoshop open (gasp!) to choose the colors. I’m sure there’s some great tools available online that provide a color picker for generating hex codes and rgb values, but for whatever reason I still use Photoshop’s. This is out of convenience, because usually I already have Photoshop open, but I’ll get to that later.
As with typography, the best color schemes come from experimentation, so have fun! Here you can see the power of an in-browser design process when you can change the backgrounds and text-colors of many elements on your page with a few keystrokes. With a Photoshop mockup, changing the colors of multiple elements was an arduous task, involving precisely selecting layers and clicking through far too many buttons a windows, but no more!
Details: Know When to Use Photoshop
Remember how I said that I usually have Photoshop open when coding a website? Well it’s time to break something to you, young padawan. Very few sites can be developed with no use of Photoshop. I mean think about it, even if you use an entirely browser-based workflow, there’ll still be at least one or two custom images on there somewhere, say, a background or an icon of some sort. Unless you know of a way of making images without an image editor like Photoshop, you, or someone else will have to bring up Photoshop or similar software to make those textures, icons, and what have you.
Photoshop isn’t all bad. My main argument in this post has beeen that it isn’t at all good for designing websites, but as an icon designing tool, it’s actually kind of great (if you ignore how maddeningly often it crashes, which I try to). In any case, at some point during the creation of a web design, you’ll no doubt have to generate some sort of custom graphics. I have no problems with PS being used for simple things like a repeating background, texture, or icon that will ultimately be part of a larger web design.
Likewise, Fireworks isn't bad either. In fact, Fireworks has lots of great features (like batch processing and advanced "save for web" tools that actually make it the perfect companion for the in-browser workflow... you've just gotta know when to use it.
We’ve come a long way in this article, but before I finish up, there are a few caveats about this process that I’d like to mention.
Client Pushback: Some clients may not like you using this technique. They might be dead set on seeing a Photoshop mockup before you do any code work. If this is the case, then you should accommodate them. You can still use a lot of the tips I’ve given here, such as trying different typefaces with Typekit or another @font-face service, or quickly iterating a design with colors. The important part of this post is recognizing that even if you mockup with an image editor, the design should still be open to change and improvement.
Even Microsoft wants you to stop supporting IE6!
Old Browser Blindspots: There are still are a lot of things that you cannot do in browser, and a lot of things that aren’t supported by older browsers. If full IE7 compatibility is a client requirement, then you shouldn’t use CSS gradients, and instead use images. There are ways of providing fallbacks, but sometimes a client will demand full support. That said, you should always be looking for ways to delegate design responsibility to CSS and to cut down of excessive image use. It produces cleaner and more maintainable markup and resources.
Be Comfortable! My third and most important caveat: you may not be comfortable with this workflow, and that’s okay! As I said before, even if you’re not ready or not able to completely follow these ideas, the important thing is that you recognize and at least try to consider some of the concepts, such as rapid iteration or focusing on layout first.
It’s that time again. Time to wrap up and really assess what you’ve learned today, which hopefully isn’t nothing. I’ve covered a lot of stuff, and with any luck, at least some of it has stuck in your brain. I’m not expecting you to all go and completely change your workflows, I just want you all to consider that there is another way to do things. It’s sometimes hard to realize that there are other ways of designing aside from the way that you do things now, but as a designer, it’s important that you are exposed to different schools of thought.
I firmly believe that this process is the future of web design, and I, for one, welcome it!