Written by on CSS Wizardry.
Independent writing is brought to you via my wonderful Supporters.
Last night I got to thinking that the majority of design and build I have done in the past few years I have done straight into the browser. Personal sites, personal clients and some clients worked on during employment–all have benefited from being designed in the browser, and their code has benefited also. I maintain that the build quality of a site designed in the browser can be far greater than if it started its life in Photoshop.
N.B. I am in no way saying we invented the concept of designing in the browser, we merely adopted it very early, before most.
I have championed designing in the browser long before it became popular. True fact. I was doing this long before it was a mainstream practice.
When working at Sense I was extremely lucky to work alongside a man called Philip Meitiner. He was Sense’s Account Director and a genuine pleasure to work with and learn from. It was whilst we were working on a white-label website for some big name clients (Nissan, Renault, Mercedes, Volvo and more…) that we decided to ditch Photoshop and dive straight into the browser. This idea was born from the fact that I’d put together a series of HTML wireframes whose code was of a quality that I deemed suitable for production. It seemed backward to us to then fire up Photoshop and design an image based on a set of HTML pages, to then return to the HTML and style it.
Thus was born our idea to design in the browser. We saved the HTML in isolation and used it as a starting point for each development of the various sites we had to build. We branded and designed each white-label in the browser and sent live, actual code back to the client for approval. It was, for everyone involved (though me more so) a dream come true.
Months later, 24 Ways published their article on designing in the browser. If there was one article I wish I’d written, it’s that one. Phil was equally dismayed, however at least we knew we were on to something good.
For those not in the know, designing in the browser is exactly as it sounds. Instead of building a website in Photoshop then markup, you dive straight into the browser and notepad and get cracking. A few benefits:
Saves time, cutting all Photoshop work.
Changing repeated elements (e.g. hyperlink colours) takes just one CSS declaration in the browser. It takes a lot of donkey work in Photoshop.
Clients buy websites, not printouts of websites. Designing in the browser allows them to see how their site looks in its intended environment.
This makes progressive enhancement usage much simpler. If they view it in Chrome, they see your round corners. If they view it in IE they see square corners. Both are intended behaviours, and both are fine.
It can show things like hover effects and interactions that Photoshop can’t.
“Clients buy websites, not printouts of websites.”
There are a few reasons why I believe that designing in the browser improves the overall build quality of a website.
Users don’t (generally) visit a website for its design, they visit for its content. Designing in the browser considers content first. This is absolutely essential for a well thought out website, in my opinion. In Photoshop you design a layout and then populate it with content. Designing in the browser you start with your content and design around it. Content is the focus and the design does nothing but complement it. You’re coming up with a suitable way to house the content you’re starting out with, rather than shoehorning content into a preconceived design.
By focussing on what your users are actually coming for, you often find that a better UX will follow. Ignore anything extraneous to begin with, nail the fundamentals (hint: typography!) and concentrate on how pretty it looks after. Designs change more frequently than content does; invest in the content early.
“What happens when your Photoshop printout uses nice anti-aliased Helvetica, and the final site renders in non-aliased Arial on the client’s machine?”
Another reason is that, particularly if you are in a team where the designers don’t do a lot of hands-on coding and build, devoting a lot of code to purely visual effects and design can lead to insensible builds, insemantic markup and a whole host of other issues. This is, admittedly, a marginal chance, but coding around the content before the design will often lead to more sensibly built websites, focussing more effectively on its content.
The main time to use the designing in the browser as your primary build method is probably with a lot more sites than you’d imagine. Blogs, ecommerce, portfolios, news sites, apps, aggregators. You name it.
Hopefully this one doesn’t happen often, but it can do…
I’m sure developers have had this countless times–a designer brings you a design that just isn’t codable. The client had been shown a PSD that you have no hope of coding unless you botch and hack at markup and use ridiculously extraneous amounts of Javascript to manipulate it. By designing at code level you avoid all these problems from the outset. What you code is your design, your design is codable.
Far from it. The designer is often the developer anyway, and if not, the designer is needed to call the creative shots and create initial visuals. Take Venturelab for example. Si came up with the skeleton of that design in Photoshop. Any type work, any calls-to-action, lists, navigation and tables were done by me, in the browser. Si created two ‘mood board’ style PSDs (and very good ones at that) but Justin was only ever shown working code, designed in the browser.
Nail the backbone in Photoshop if needs be, but in areas where rapid development and the need for quick and arbitrary changes are needed (think typography and link colours etc.) designing in the browser is far more efficient. Imagine the pain of changing the zebra-stripe colours of a giant table in Photoshop when you just edit one CSS declaration and see to it all in one go.
There have however been one or two occasions in my career where not designing in the browser has done more good for a project than bad.
“There’s a large chance that [a developer working in the browser] won’t make things difficult for themselves, that they won’t push their boundaries. This is a bad thing.”
The first example links back to what I said about designers handing sites to developers that the developers can’t code. If the person designing the site is also the person building it, there is a (pretty large) chance that they’ll take the easiest simplest route to completion. There’s a large chance that they won’t make things difficult for themselves, that they won’t push their boundaries. This is a bad thing.
If I draw on my own experience, the Findus Crispy Pancakes site is an excellent example of designers giving developers the kind of headaches we love. I built Findus about a year or so ago whilst at Sense. Rob designed the site in Photoshop and when I saw it I nearly fainted. I had no idea where I’d even start coding up such a complex looking, overlapping, quite frankly mental design.
Yet despite this, I got my developers brain on and got to work. I finished the site about four days ahead of schedule and enjoyed every minute of it. That design pushed me more than it would have if it had started out in the browser. It was a lot better for being in Rob’s hands first. And I still maintain that it was one of my most challenging builds to date (IE6 support…).
Follow Rob on Twitter. Fantastic designer and all-round nice guy.
It is important that the designer and developer have overlapping knowledge of each others’ respective areas, yet play to their fullest in their own. The Findus site was a bit of fun on a small project which allowed me and Rob to really stretch ourselves, and that’s what it’s all about.
Another couple of times where designing in the browser hasn’t been viable was when we, at Sense, were working on the Travelodge and Rizla websites. Travelodge was designed by another agency anyway, but even so, as they had very stringent brand guidelines that stated that round corners were a pivotal part of the brand, everything needed to be done in Photoshop.
Another example would be Rizla, which, again, we built at Sense. As Rizla’s brand is so important to their success and recognition it could not have just gone straight into the browser. Rizla wasn’t so much about quickly accessible content, so much as heavily designed and branded content. We allowed for users to change the design, and for the design to carry off promotional work, which could not have happened straight in the browser.
This section was edited in part by Dan Bentley.
Programmers manipulate markup. A Photoshop document is nigh on totally useless to a programmer, whose involvement lies in all that magic stuff that happens behind the scenes. Allowing programmers access to the code from an earlier point means they can start their job alongside the developer sooner.
Furthermore is the idea that Javascript developers can visualise their involvement much sooner, too, and see what markup they will be manipulating from the outset, rather than having to second guess what markup might result from the developer’s take on the PSD. They can start manipulating the DOM and begin building prototypes alongside the main build developer right from the start, making life easier for them as well.
At every available opportunity.
It saves time, it’s a much better way of presenting concepts to clients, it leads to better quality builds, it gives more consideration to content, it’s more fun than working in Photoshop (at least from my point of view), it’s easier to experiment, it’s far more efficient and the quality of the code is usually better as it concerns itself with content over decoration.
“Designs change more frequently than content does; invest in the content early.”
For any content-centric sites (I know, all sites are about content) such as blogs, web-apps, CMS style dashboard builds, news sites, informational sites or anything similar, you can’t lose by designing in the browser.
If you’re an account manager type person at an agency, run the idea past your development team; I’m pretty sure they’d love to work like this, if they don’t already.
Sometimes, designing straight in the browser just can’t work. Heavily branded or very graphical sites that are more about decoration or branding than content will be a struggle to create without opening Photoshop first. However, by completing the major chunk of the layout and graphical design in Photoshop, you can often leave it at that, and model/work on type straight in the browser (what happens when your Photoshop printout uses nice anti-aliased Helvetica, and the final site renders in non-aliased Arial on the client’s machine?). For the fine details, designing in the browser will be far more efficient and true-to-life than using Photoshop will ever be. Embrace it, and enjoy it.
So, do you design in the browser? Are there any reasons why you don’t? Would you like to? Leave a comment and open the debate up a little wider…
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。