We’ve come such a long way from the times when CSS was just starting to become mainstream. It is now a widespread technology, with all browser makers offering wide, though still not complete, support. So maybe it’s time for another change.
A few months back, a thought popped into my sick little head: what the heck do we need software like Photoshop for? I didn’t pay much attention to it back then and decided to bin that idea. However, about a month ago, I noticed a conversation going on Twitter, mostly between Eric Meyer and others, about “Designing in the browser”. Each party had good points of view on the matter, but most were contrived or subjective. I’m talking about arguments the like of “you can’t do all the cool things you can do in Photoshop, with code”, or “Photoshop is meant for editing pictures, not for making websites”. That sort of thing.
One of the arguments I favor most of that conversation Eric Meyer had with a few people for why you shouldn’t design in the browser is: “designing in the browser hinders creativity because you’re only going to think about the code; your mind is stuck in a browser environment”. I’m sorry, I thought I was designing websites FOR the browser environment. I wasn’t aware my web design was meant for a 10 foot banner.
I decided then and there that I was going to give this a try, I mean, how hard can it be? So I set out to design in the browser and in the browser alone. I’ve gone through three projects this past August with this process and I must admit that I’ve learned more about web design this month than I have for the past two years.
So, what sets apart In-Browser Design, as I like to call it, from the more “traditional” approach?
Speed
You’re basically cutting design time by 75%. At least I did. Not having to go through designing a mockup meant that after the client sees the design and approves it, the website is done. Needless to say, that makes clients hella happy. This does mean that clients need to be informed about what you’re doing. If it’s a Photoshop mockup that they want and they won’t have it any other way, then that’s what they should get. I was fortunate to be able to do In-Browser Design with actual clients; others might not.
Focus
Content is king is something we hear all over the place, it’s become our motto and a constant reminder of the priorities of building a website. But so many designers still forget about this simple directive and the reason why so many still fail to put content first, is, in my opinion, partly because of the work environment.
Think about it, what is Photoshop about? First and foremost it’s about graphics. We know this, we understand this, this is why we turn to it; to make graphics. Now let’s look at websites. What are websites about? Content. In the same way that Photoshop without graphic tools is not Photoshop, a website without content is not a website.
So, by moving into the browser, intertwining code and design, the designer’s focus gets shifted from the graphics to the content, which is where it should be, when it comes to websites.
Code
As web designers, our life is torn at, somewhat, opposite ends: at one end we’re artists struggling to create art, beauty, self-expression; on the other end we’re analytical, we’re pragmatic, we struggle for clean code, semantic tagging, logical user interfaces and sustainability. This designer dichotomy, I think, is unhealthy. It breeds three types of websites:
- websites that are gorgeous, but their code is ugly as sin
- websites that are ugly, but have spotless code
- websites that are mediocre, with mediocre code
What In-Browser Design does, in my experience, is break that dichotomy because it reverses the traditional order of things. By tradition, we first create a design mockup, the client gives the ok and then we start coding.
With In-Browser Design, you start coding the HTML from day one. Structure, semantics, code cleanliness and all those things take focus first. It’s only after the content is set in page that we can start focusing on design. By that time you’re well familiar with the content, you understand the underlying structure that you’ve laid down and your mind can focus on design and beauty and art without worrying about “can this be coded?”.
Proper progressive enhancement
Those of us who adhere to the progressive enhancement philosophy are, most of the time, adamant about why it is so important. But, to really have proper progressive enhancement In-Browser Design is the only true path worth taking.
I’m coming back to this, because I think it’s such an important step, a real paradigm shifter. Start out with the basic HTML (and PHP/Ruby/etc. if your page is dynamic) and the actual content, work your way up to CSS, then Javascript if need be. Progressive enhancement and In-Browser Design are a match made in heaven, if there ever was one, there is no doubt about this in my mind.
Interaction
When doing a mockup, you’re forced to work with a static entity, there’s no going around this. But, with In-Browser Design, you have hover states, selections, inputs, textareas, buttons, all the things that users interact with on a website readily available to you to test out, just like a regular user. It is immensely gratifying to be able to experience the full interaction that users will have with your website when in this design phase.
CSS3 Super Speed
You knew I was getting here. Part of designing with code is that you’re concerned over something that should also concern traditional web designers during the design process as well, though it rarely does: page speed. It’s quite simple and I’m sure most of you reading this already know about it: the more images you have, the more HTTP requests, the longer it takes for a page to load. Let me just stop you before you start your rant and I’ll state that large sprites are not a solution. Why? Large sprites = lots of Kb, pure and simple; load time goes up, again.
*I am, however, not an advocate for extra markup just to replace an image with the aid of CSS3. My point of view is simple: if it doesn’t require extra markup and it’s doable with CSS3, then I’ll do it. Else, use images.
Enter CSS3. Gradients, rounded corners, shadow, @font-face are but a few of the slew of goodies that CSS3 provides. I’m a pretty big advocate of CSS3 over images* so In-Browser Design is the perfect meeting place for me to settle the two. There are things that no CSS3 magic can do, and that’s fine, I’ll go for images on that one. But where there is room for CSS3, I’m sure to use it. And all this is coming back to progressive enhancement, of course.
Those are all well and fine, but there doesn’t seem to be anything new being brought to the table here, is there? In the hands of the most skilled designers, Photoshop is a mighty weapon, wielded to build some of the most amazing websites we’ve ever seen. I’m not arguing that Photoshop/Fireworks/Gimp/Paint Shop Pro/Pixelmator etc. aren’t great tools. Far from it. I’m arguing that they are not meant for the web (Fireworks included, but that’s another story). I’m arguing for a new paradigm for building websites.
It’s no mystery that I am completely hooked on this new philosophy and it’s in my nature to speak about it loud and proud, so let me make amends for what could probably be seen as a very emotional editorial on some occult practice of making websites. I don’t want you to start doing this from now on. I don’t want you to think that traditional website design is bad. What I do want you to do is keep an open mind. And if you’re feeling adventurous, maybe even give it a shot once. See if it’s for you. If it’s not, no harm done. If it is, then step into my office and whatever I can do to help you with this, I will.
I like to look at this In-Browser Design philosophy as Website Design. Not coding, not code while designing, but purely Website Design. Because that’s what it is, by excellence even; you are able to have full control over every aspect of your work, it’s truly WYSIWYG and that’s more than I could ever wish from a web design environment.
Great post mate,
I agree with you. The last few sites I’ve done predominantly in the browser and then I’ve gone back to Photoshop if needed.
To be honest, if you sketch the design out first then you won’t be constrained by thinking about code etc then you can look at the design and think ‘yep, I can do that with CSS3, that with Photoshop’ etc. Choosing the right tool for the job.
Thanks again!
“The right tool for the job” is what it’s all about, really. Code is the tool for the job of making websites, a graphics software is not.
It’s great to see other people are venturing on this road, successfully even. And thanks for your comment!
I’ve been fortunate enough to do some of this over the last few months. It’s hella cool and does save some time. hella.
I do this, however I usually sketch out a rough idea on old fashioned paper first. I find drawing to be a more effective way of getting my ideas out of my head into something visual
Roughing a wireframe on paper, or even in Photoshop or a dedicated software solution isn’t something I was arguing against. This part of the design process is mostly conceptual, giving the designer a basic idea of what will be built. I sketch on paper too, often times geeking out with maths and stuff, so I know where you’re coming from. There are projects where sketching is really essential, I would say, especially when it comes to very large, dense sites. Thanks, Nico!
I would like to see this website that you built, to prove your point that a coded design aesthetically presented the content better than a static photoshop design could.
While you can’t actually prove that non-photoshopped websites are better than their ‘shopped counterparts, I see your point. Well, for starters, you’re looking at a website that was built without a Photoshop mockup. But this is my own site, so maybe it’s not that relevant, right? Well, unfortunately, it’ll have to do, seeing as I’m bound to confidentiality by my working contract. And no, that’s not a “well isn’t that handy” moment. I’m sure most designers working full time can relate to this situation.
Coming back to my original point, though, your request is quite futile as one would have to be in two places at the same time to accurately prove whether one is better than the other. And even if you could do that, the result would only apply to the individual doing the testing. In the end, whether you try this method or not, it’s you own choice. There’s no right or wrong here, just two different ways of looking at a problem. Hope that clears it up!
I totally understand what you are saying. I just find that now we are in an era where just about anything can be justified, but nothing is actually proven beyond reasonable doubt anymore.
No offense intended (as I haven’t seen the design or any of your work) but I was honestly anticipating a Web 2 design built to 960px grid … if you know what I mean.
There are alot of perfectly valid concepts floating around the digital design and development industry at the moment (CSS3,HTML5, accessibility, mobile technology, browser compliance) which are great in themselves, but web design and development posts are seldom analised and tested in the wider context of our field as designers and developers.
Just wanted to see if this article was more than a nother concept.
No offense taken; I appreciate you taking the time to discuss this further. I like to think about In-Browser Design as more than just a concept. To me, it’s a new direction, a different way of looking at web design, not just a weird and possibly interesting idea.
But, as I mentioned towards the end of the post, I’m not saying you, my readers, should go out there and start doing this because bla bla and bla bla. I’m saying give it a shot. If it’s for you, fine, welcome to the gang; if not, that’s fine too, I respect you just as much and your work is no less important or valuable.
I tend to use a mix of paper, whiteboard, browser and Photoshop, in no particular order, and varying according to my needs at any given time.
For example, I’ll regularly start on paper, end up with an in-browser design that I’m not quite happy with, then copy it into Photoshop, slice it up, tweak, and bring elements back into the browser as I go.
At Really Simple, we always try to have an in-browser wireframe quite early on (way before any semblance of a polished design), and this does seem to make the rest of the process flow better, especially with UI design, as interactivity is a major factor.
I like your pragmatic stance on the use of CSS3 – I think we’ll see plenty of hearty debates on issues like this in the coming months!
Nice article. Thanks for share.
I was interested in your bit where you mentioned…..
“the more HTTP requests, the longer it takes for a page to load. Let me just stop you before you start your rant and I’ll state that large sprites are not a solution. Why? Large sprites = lots of Kb, pure and simple; load time goes up, again”
You’re completely right on both fronts, as the number http requests go up so does page load time, and as the size of files go up so does the time it takes to download the file.
While CSS3 offers the perfect solution in many cases we all have those clients that demand a more consistent site across all browsers (yes, even ie6 *shudder*).
I think that CSS Sprites are the perfect solution because
1) In this case the sum of all images is less than all it’s parts (i.e. 10 images of 5kb size will equate to 50kb however a sprite of those images will only equate to appox 35kb)
2) On a large site implementing a CDN will speed up the total load time of the single file
3) Setting up suitable expire headings on the sprite will mean this hit will be felt once and never worried about again (or for a while at least)
Of course, if you can get away with JUST CSS3 then even better, but it’s a pretty good solution otherwise.
Loved the article though, I’m pushing our company to move towards this but I’m still waiting on the right client to kick off the process.
I agree with you, if the client wants cross browsing all the way to IE6 then, yes sprites are the way to go. But, as you put it “if you can get away with JUST CSS3 then even better”! Thanks for your comment.
Thank you for your very thoughtful article, Radu! It is always gratifying to learn from someone who has put a theory to the test.
Ever since reading Meagan Fisher’s article about it in 24Ways I have also been keen to take a crack at it. It just appeals to me on a conceptual level. The web is intrinsically a dynamic, multi-dimensional beast – to deny that fact is to miss out on the potential presented by the medium.
It forces one to deal with the content first and foremost – rather than as an afterthought. Which is so easy to slip into when creating a beautiful “skin” in Photoshop.
I also think designing in the browser lends itself to an extra element of “play”. Allowing the opportunity for “happy accidents” to occur and to be explored. Fundamental shake-ups of processes can only serve to benefit the designer (if not the design itself).
I can’t wait to try it for my next project!
Nice topic, I really agree with you , In-Browser design is much faster, ( new term I learn today ) , Andy Clarke said something also about this stuff.
Thanks
Thanks for the article.
The thing is, designing in the browser isn’t really a new idea. It seems to be a concept that the ‘new’ generation of web designers are starting to realise.
I’ve always designed in the browser (starting in 1994) and used Photoshop only to produce graphical elements when needed. I usually started with a vision in my head or if it was complicated I’d sketch a wireframe on paper.
This is probably because in 1994 there was no such thing as CSS and web design was a very limited art form at the time. But it’s something I’ve carried with me as the technology has evolved.
I fundamentally disagree. Design is not simply a process of arranging a bunch of elements in a pleasing manner. If you let your tools dictate the design process then you will create nothing new.
Good article. I’ve been doing in-browser design on a side project these past few months and have loved it. As someone who finds coding in an editor more natural than designing in Photoshop, it was a real breath of fresh air.
I too discovered huge time benefits with this approach, and also a lot more flexibility. I could try out new ideas very quickly, right there in the browser, with just a few HTML/CSS tweaks.
All my HTML/CSS was version controlled in Git, so if I found myself going down a path which wasn’t right, I just rolled back. No need for saving multiple copies of massive PSD files.
Having said all that, this particular project required a very clean, graphics light design, which definitely lends itself to in-browser design. If I was working on a more visually complex design, I can still see the need to fire up Photoshop, at least in the beginning to get the skeleton of the design looking right.
Thank you for a well-written and insightful article. I do think that in-browser design can put one in the right mindspace for designing for the web. However design is so much more than content. Truly great design comes from the organic process of creation, and I would argue that working solely inside the browser inhibits this process.
Saying that “content is king” does not negate design. Yes, it is important to present content logically. But it’s rare to find websites built purely around content that are also beautifully designed. There is much mediocrity on the web, and I think most of it comes from a lack of foundation design knowledge. And as much as I’d like to support the concept of in-browser design, I fear it will only push us further from the basic critical skill set required to create websites that are beautiful, not just functional.
I have very positive feelings towards this sort of work. One question though, when you say “extra markup just to replace an image with the aid of CSS3″ could you give me an example of when people do this?
i don’t understand your workflow of “In-Browser Design”
Information Architecture – > HTML Docs – > mocks-up with CSS
sounds like it’s barely impossible to complete a graphically complicated website just out of your css code and some simple images that are probably not crafted out of photoshop.
it’s really difficult to satisfy your clients with such simple designs.
In a blog design it’s ok, but in a large CMS?
Maybe you can explain more about the procedures of “In-Browser Design”
Hello Radu,
this is what I do since late 2004, and as Heath just said above, I saw the first spoke on this at 24ways Meagan Fisher article (Make your mock-up in markup). But also at 24ways you find another article from Andy Clarke, named Ignorance Is Bliss whici points the most important point from business perspective about In-browser design.
Well, congrats for the post, and keep going with good practices.
I’m so glad people now talk about In-Browser Design. I’ve been designing directly in browser for the last 10 years! Mostly I don’t even need to write HTML code now, just using a powerful CMS, which supports nested layouts and standard content components (RTE, picture gallery, quotes, menu of subpages, contact forms, login form, registration form, product list, product detail, etc) and stick them there.
My design process starts with some initial information architecture, getting content from my client for each page, building prototype using REAL content and than get approval for that layout. So I have my wireframes/prototype directly in CMS and I start to stick in all artwork and editing CSS, all in the same environment. I can understand 90% of web designer cannot use process like this, because they are using limited CMS like WordPress or Joomla, which are not suitable for this kind of work… Using process like this allows to get a screenshot at any stage and do some adjustment in any bitmap editor when needed (Pixelmator, Photoshop, …)
I must really be behind the power curve… I have NO idea whatsoever on how to use PhotoShop to code a webpage…didn’t even know it was possible… sigh…
Vawy interesting reminds me of that movie “Kingdom of Heaven”. The Bishop or somebody asks Orlando Bloom’s character, “who are you, you think you can just change the world” hehe. Well the web is all about change and really this seems more a question of work flow than a question of the actual tools you use, and it makes perfect sense to read but practical application of this method may sit differently with each designer like you rightly said. I am sure Photoshop still has a firm place in your heart
– I am actually looking to re-invent myself as a designer (…that’s code for actually doing some work) and redesign my own site so I will give your world changing method a shot Mr. Radu. Good Stuff as usual. Cheers.
information architecture and interaction design is essential even in smaller web sites. This is usually done on paper or some wireframes or prototype tool like axure.
You will have a great understanding of content because it is researched in the IA. You can then flesh out some UI concepts, to determine what works best. Discuss it with the client and make user testing.
the step after that is to make it more visually appealing with typography , grids and finally colors and elements of branding. I find it very limiting to do this in the browser.
visual aesthetics and good typography is something I prefer to do in an environment that is built for it. if I want to try some typographic combinations, move elements around, change colors, whatever I can do it in seconds, while I’m looking at the design. I don’t have to spend time rewriting something that most possibly took a while to make.
I also get a good idea early in the project how the finished product will look like. This is a strong selling point to clients.they know the functionality thanks to interaction design and they know form thanks to the mockup. Branding is important. if they have some complaints in the late stages of a project it could become very time consuming to change. Let the client know how it will work and look, and perform user testing / research before you code is good practice.
When I design I do have a good sense of web standards and I know what works so with that in mind I won’t design something that will be impossible to write.
you design for users, not for browsers. in browser design might work if you make detailed concepts and wireframes but otherwise I prefer the mockup.
Maybe things have changed, but designing in the browser is a testament to how design is consistently becoming a factory. Get designs assembled as quickly as possible and get them off the conveyor belt. Unless someone is a savvy designer as well as a developer, this method may not work well.. if you’re terrible at either one, I’d suspect multiple edits to codes and a lot of wasted time programming when a client doesn’t like what she sees.
I continue to design in Photoshop because the browser is still a canvas to explore. Skip the art part, and design will all look the same, sites will all function the same because the designer put code over everything else. Just my opinion. If it has to do with interactivity and content becoming more important that just a place to visit like it used to be, then I guess it can’t be helped that that conveyor belt will only run faster from here on out.
I do see where you are coming from. However, the 3 types of websites this breeds…I think that has more to do with the ability of the people making the site than the tools they are using to make it. They either understand what they are doing and understand how to do it, or they don’t. People have a wide range of expertise in this industry and few are can make very nice looking *and* well coded sites. Most end up as one of the 3 types of sites you describe simply because of how they learned, and what aspect(s) of website creation they are most interested in. Let’s face it, our industry has become like most: there are specialists, and there are general practitioners, and each have their time and place.
I like your attitude, Janice, but, as I’m sure you realized, I was not referring to those special few that can bypass the 3 types I describe in the article. They are industry leaders and people we all look up to. The tools we use do have an impact on how we do our work, just as much as an ax leaves a physical mark on the person yielding it. But with a bit of effort we can learn to use both a quill and an axe just as well. It just takes dedication and ambition.
I can agree to a degree when people say they “design” websites directly in the browser.
I 100% agree that it’s possible, but I think there are downsides to this approach:
- it’s more difficult to sketch and really think conceptually, because you’re thinking “in code” to design something.
- Some things/effects are perhaps not impossible to code, but they’re easier to pathom and create when you’re in Photoshop (or whatever program you use), not to mention the ease to change the look of things. Changing the looks (not the colour) of buttons for example, gives you more creative freedom in my opinion
I do see the upsides in designing “in” the browser, primarily in the speed gain and cleanness of code in most cases. But I’m (with exceptions of course) of the opinion that you design in a design program, and code in a code program… to an extend, since you can design gorgeous elements directly while coding
Good article, I’ve been wanting to go designing in browser for a while now, but have been unable to do so at work.
I can see advantages to both, really. In css it’s incredibly easy to make changes to colour or typography throughout the whole site, something which is incredibly annoying to do in photoshop. But photoshop is more blank canvas than code.
“designing in the browser hinders creativity because you’re only going to think about the code; your mind is stuck in a browser environment”
Funny, when I design by code (98% of the time) I invariably come up with design improvements along the way (= creative thinking, right?) whereas when I design in PS or AI … the design usually becomes less vibrant and anyway as I code the PS/AI design I invariably come up with design improvements. Hmm.
Thanks for the article. I already do this, since the 37signals blog post a few years back. But it’s always nice to get confirmations.