guru24
Member
We know that print design does not translate directly to the web successfully. The are many reasons for this and without launching into a list of do's and don'ts, I'll just share a recent experience which illustrates a few of the problems quite nicely. Some of the things that cropped up on this project almost left me speechless.
As a developer - front-end and back-end - I often take the UI design from other sources and pick up the build from there. I always offer guidelines and advice when I feel it might be needed in the earlier design stages, particularly where a design is showing early signs of bad usability. Sadly this is still far too common, but that's another story.
For a recent project I was provided with some designs and artwork by an agency (producing for their client) which were obviously created by a print designer who did not have much understanding of the online/web browser medium. Here are some of the more remarkable issues which arose:
By the way, all of this is true and all in one project! It's not unusual for some of these things to happen, but this project simply beggars belief.
Conclusion? What we already knew: it is absolutely vital for designers to fully understand the online and interactive mediums. Some print designers can move to Web successfully, but when it goes wrong, it can turn into a total train wreck.
As a developer - front-end and back-end - I often take the UI design from other sources and pick up the build from there. I always offer guidelines and advice when I feel it might be needed in the earlier design stages, particularly where a design is showing early signs of bad usability. Sadly this is still far too common, but that's another story.
For a recent project I was provided with some designs and artwork by an agency (producing for their client) which were obviously created by a print designer who did not have much understanding of the online/web browser medium. Here are some of the more remarkable issues which arose:
- visuals were created in Illustrator and supplied as EPS files, complete with images in CMYK - one page was over 35MB and it wasn't particularly complex. One of the many problems caused by web artwork/visuals in a vector format is that fonts in body type sizes are often way too small when the layout is sized to a typical 960px wide browser viewport. This throws the whole balance of the layout when you scale up the text to make it readable.
- the whole site used a background graphic, the design of which was fine diagonal stripes with a top left to bottom right gradation - basically non-tileable and the worst possible design for compressing in any file format. To look good, the background graphic was over 1MB and even compressed quite severely as a jpeg, it was over 300k.
- the client was not sure exactly what width they wanted the site to be. It was requested I use a width that matched what the client had seen when they viewed the PDF visuals on-screen. Of course, PDFs can be viewed at any size and even at 100%, different platforms and different viewers scale PDFs differently on screen. This one was unbelievable!
- the overall site layout had a fixed height with an internal scrolling frame, so to accommodate the main body content, I needed to use a 'scroll on overflow' DIV - looks like an iframe, but doesn't have the problems of an iframe. Because the fixed layout height was deeper than most browser viewports, this ends up giving you a double scroll bar scenario - one in the central content frame, plus the browser's main window scroll bar. Now, users who don't have a suitably high res display need to scroll the main web page to centralise the content frame, then scroll that frame to view all the content. Utterly crazy.
- the site was built on a CMS which was just about the only element of the project that worked successfully. The page layout incorporated fixed height design elements which of course didn't always accommodate the variable amounts of content they ended up containing.
- the layout had a fairly strict five tab main navigation. Some pages are reached via in-content links, but as these are not represented anywhere in the navigation, users end up finding themselves on a navigation island with no sense of where you are or what your current page belongs to.
- some of the content was supplied as MS Word docs, with the intention of being downloaded by users and read in Word! Even worse, these were placed in HTML pages on the end of a 'read more...' link with no warning that a Word doc would be downloaded and a bulky app launched. A PDF would have been slightly better, but there is still no reason why this content had to be downloaded and read outside of the browser environment. So, you read the first paragraph on a web page, then you need to download a file to read the rest of it!
- being a multi-lingual site, the main nav tabs would not accommodate translations such as German which has a much higher character count than English.
- to add insult to injury, they insisted on adding a Flash splash screen at the front door of the site. Sheesh!
By the way, all of this is true and all in one project! It's not unusual for some of these things to happen, but this project simply beggars belief.
Conclusion? What we already knew: it is absolutely vital for designers to fully understand the online and interactive mediums. Some print designers can move to Web successfully, but when it goes wrong, it can turn into a total train wreck.