In the past, many companies and web designers had a workflow that was two or three parts, minimum -- design, markup, backend. These are generalizing and the lines may blur a bit... but I'm sure you get my gist.
Often the web designer was "visual only" and would only be responsible for constructing a very detailed mockup in image editing software, such as Photoshop or Fireworks. The mockup(s) would show every possible aspect of a web page from colors and type choices, to backgrounds, icons, photos and other images to be used. But the "designer" was never concerned with actual live construction and implementation. They were solely focused on the appearance.
Once the design was approved (by reviewing these image files) stage two was undertaken - transitioning the image file(s) to live HTML/CSS.
In a single-seat or freelance environment, the web designer may have used slices and exported to HTML via some internal application options. On rare occasions the designer may construct basic HTML/CSS page frames.
In some corporate environments, these mockups would remain in the form of a layered image file (.psd, .png [for Fireworks]) for the web designer and the designer would never worry about implementing any markup or code. The "designer" never had to concern themselves with how to construct HTML or CSS in order to implement this image mockup they created. Image files were/are handed off to a "developer" who is then responsible for constructing HTML/CSS which matches the image file.
I imagine some still very much work this way. However, with the advances in markup languages, namely CSS3, and browser support improvements -- in many cases the time spend carefully constructing a raster representation of a full web page can be largely useless in many cases.
With current mark up it's very easy to implement many web design needs directly via HTML/CSS and use of image application is limited to generating small image assets or photographs which may be needed. (Libraries and/or templates such as Bootstrap have further pushed this notion.)
In my own workflow I've notably moved away from full page mockups unless they are specifically requested. I do this in order to improve design speed and ensure that what is approved is close to what will be finally rendered in browsers. In fact, I haven't created a full page mockup in a number of years. But I am aware there are still workflows using this method.
Is there any real benefit to constructing full page mockups in image editing application prior to diving right into HTML/CSS for design construction?
Answer
The benefit of constructing full page mockups is the division of labor.
In larger companies which have both a designer and a (front end) developer, the job of the designer is to design and the job of the developer is to write code.
Having this division allows the designer to spend all of their time working on the look, feel, and interface for the website and not have to know anything about how it is created. They can create higher quality design and think through decisions for longer precisely because they are not working on getting the code to do what they want at the same time.
It also lets the developer write more code by not having to think about how any of it will look including the small details and varying states. They implement the design as best as they can in the time given and can move on to another project.
If the designer is the developer as well, I think most people more or less are starting to side with you in that they create a more rough product and iterate quickly to test things out. This allows ideas to be tested quickly as opposed to creating a pixel perfect photoshop document.
However, rough, iterative design without code is also a valid and incredibly useful approach especially for layouts and work flow. Markup languages and new technology didn't invent working quickly with rough ideas :)
No comments:
Post a Comment