homepage Welcome to WebmasterWorld Guest from 54.226.133.196
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderator: open

CSS Forum

This 37 message thread spans 2 pages: 37 ( [1] 2 > >     
Complex Layout guidelines for designers
What is practical, what to avoid
thesheep




msg:3160792
 11:35 am on Nov 18, 2006 (gmt 0)

Many media agencies still have a division between graphic designers and front end coders. Creative types produce a lovely set of visuals in Photoshop, then pass these on to technical types to convert into HTML/CSS.

The problem with this, at least in my experience, is that the designers don't understand how web pages are constructed. This causes problems at the build stage, particularly in the case of more complex layouts that require liquid behaviour.

Very tricky things seem to be liquid areas that require multiple columns of identical width, and layouts where design elements from one column overlap another liquid column. In my experience you can find ways round these things, with time and patience, but the real nightmare starts when a layout includes a multitide of these kinds of issues, because things get exponentially complex to build.

Given the constraint that we can't suddenly oust all the talented creative designers from their jobs, or retrain them in the nitty gritty of CSS and browser inconsistencies, does anyone have any solutions they've found for these problems?

I'm currently working freelance as a front end coder at a media agency and I was thinking how handy it would be to have a manual of design guidelines that would help designers produce practical layouts suitable for advanced CSS layout techniques. Does anyone know if such a thing already exists, or could we start one here?

 

yuval_raz




msg:3161371
 7:42 am on Nov 19, 2006 (gmt 0)

hi thesheep,
i have found it very convenient to spend some time to sit with the designer and give him/her some insight about the problems i (as a front-end developer) might encounter with some designs.

the conversation most often sums up as DOs and DON'Ts for a web-designer. i explain what can be done, what can't be done and what can be done but will take a lot of time to do.

FWIW i have gathered a lot of points on the subject throughout my career as a front-end developer and took the time to integrate them into a document/article for referral.

problem is, it's written in Hebrew, so it could take me some time to translate it. yet if there is clear need for it i will be more than happy to take some time on the weekend and translate it into English.

have a pleasant week,

yuval

swa66




msg:3161800
 9:13 pm on Nov 19, 2006 (gmt 0)

It's my opinion that as soon as somebody starts to draw in a pixel based drawing program, the problems you'll face -if your goal is to get to a fluid layout- are immense.

Problem is that you have to teach them they do not know how wide, how tall, the aspect ration of their drawing will be, nor do they know the font sizes.

If they can draw something that still works regardless of canvas size and font sizes, your work is almost done. If they can't better make some mock ups and agree on them before you start to code it all.

Next teach them about floats, and try to get them to not go overboard in a column way of thinking. This last one helps a lot in fluid designs as it'll avoid many problems.

If they give you a graphic that is "must be like this". You might as well split it in cells and put them in a table. Converting the text parts back to real text and hope they can live with the slight changes that makes.

It's much easier to work with designs made in vector graphics instead of pixels, as you can ask them to make it on a number of canvas widths without resizing the elements themselves. Moreover you can then most likely discuss to reduce the size of all graphical elements to a reasonable size for a 800x600 screen.

Also teach them that page filling backgrounds and fluid layout don't work well: either it gets repeated or either a part is cut off.

So I'd try to get them to switch from "photoshop" to "illustrator" ;-) first. After that teach them and show them what fluid means, and what floats do. Also show them 800x600 screens and too large graphics, next switch to a high res and show them how small their graphics ought to be.

rocknbil




msg:3161838
 9:56 pm on Nov 19, 2006 (gmt 0)

I've dealt with this in both the printing industry and on the web. The response is almost invariably "I'm the designer. You're the underling. I'm not going to do your job for you."

Of course, the actual response is not always so rude (although it has been) it is still the bottom line. I've encountered many situations where it's just easier and less expensive in the long run to follow their lead, make it happen, regardless of the difficulty. It's all billable.

The explanation comes up when they ask WHY it was so expensive, or when absolute "impossibles" arise. But I've also learned that education is every bit as billable as actual work, make sure the clock is on.

swa66




msg:3161877
 10:28 pm on Nov 19, 2006 (gmt 0)

Guess it also depends if you're the customer of an external designer converting it to a web format, or if you are a subcontractor of a designer crafting the web layout for them.
It could also all be in side the same company (and I understood the OP was talking about that).

But even when you're the customer or deal with it inside a single company, I've seen too many designers exhibiting an attitude problem.
From work I've done with a TV station in a long ago past, the trick is to have a "producer": he's the all powerful being that pushes all about and listens to all. Since he's generally responsible for the end result, it's generally steered towards the user/viewer and the money-wise bottom line. [Perhaps I was lucky with that one producer, but I have fond memories of that project]

thesheep




msg:3163918
 5:12 pm on Nov 21, 2006 (gmt 0)

Thanks for all the replies. It is an interesting subject.

Yuval - that's a great offer to translate it from Hebrew, but it sounds like it would take up quite a lot of your time. Maybe I should put together what my idea of the guidelines should be, then post them here and see if you agree.

swa66 - interesting idea about getting them to do several designs at different resolutions. I did wonder about this myself and I think it is a good idea, if only to show the client how the layout will vary. I'm not sure it is necessary to shift from Photoshop to Illustrator to do it - I think these guys can hack pixels pretty quick to get different sizes etc.

To be honest, the designers where I'm working are pretty good in this sense: they do consider how the layout will stretch. The problem I'm facing more in my situation is just that the coding complexity of certain types of structure can get very tricky and result in heavy pages, with a very much extended build time.

I will have to give the guideline thing some more thought and maybe post back here.

junai3




msg:3164148
 8:09 pm on Nov 21, 2006 (gmt 0)

I agree with yuval_raz, you need to sit down with the designer and talk about everything. What works and what doesn't. Then, after you get the designs, discuss it again. What works, what doesn't and how the design can be improved to better work when building your HTML/CSS.

Not communicating with my designers has resulted in big mistakes within our firm where entire websites had to be completely redesigned because the design was not discussed.

timster




msg:3164173
 8:35 pm on Nov 21, 2006 (gmt 0)

In my experience graphic designers are (not surprisingly) visual learners. Show them a good example of a liquid design that meets the goals, and maybe a couple that fall down in a couple places, and they'll probably "see what your talking about."

For a years to come yet, there will probably be many good designers who aren't able to "let go" enough to do web-style liquid design well. Keep the conversation focused on the customer and the end-user.

carguy84




msg:3164191
 8:46 pm on Nov 21, 2006 (gmt 0)

I think a good web designer will know what works and what doesn't, and those designers who don't know, should sit down with the coders and have it explained why something should be changed. It's not their job to know the "limitations" of HTML, but they can certainly be trained.

However, and I'm not trying to be arrogant or anything here, but I've never received a design I couldn't code up. I find you get the best results when you let the designers run free and then work around their designs. Your site visitors aren't going to care that the design caused you more effort, they're going to notice how well the site is designed.

About the only trouble we ever run into is when fonts look nice and anti-aliased, but then they're presented as actual text and are all jagged. A quick meeting with the designer to see if there's a way to make it look good as plain text, and you're back on track.

Chip-

Murdoch




msg:3164215
 9:19 pm on Nov 21, 2006 (gmt 0)

I think it really depends on your sector, and how content oriented the page is. Usually, for example, if the homepage has a lot of crawlable content, you can get away with "nice font" images in certain parts. Also, it is hard to find a nice font that will render well in all browsers (I find Verdana works pretty well at 10pt and above)

jessejump




msg:3164372
 12:18 am on Nov 22, 2006 (gmt 0)

>>>>> The problem with this, at least in my experience, is that the designers don't understand how web pages are constructed. This causes problems at the build stage, particularly in the case of more complex layouts that require liquid behaviour.

Are you saying designers that work on professional web site teams don't know about how web pages work? About liquid vs. fixed? How can this be?
People really create pages in Photoshop for the design?
I would think someone a long time ago would have gotten everybody who work on a team to understand all this.
The web is 12 years old. Everybody web surfs - they see liquid and fixed pages.
I find this all hard to believe. This was an issue 10 years ago.
The old saying: "The web is not DTP".

Setek




msg:3164464
 2:14 am on Nov 22, 2006 (gmt 0)

I work with my designer during the design phase, but she has a fairly good understanding over the years of working together what is possible and what isn't. It's not like designers can't learn...

My process is much like junai3 said - discuss during, and discuss problems after. Pretty much always, though, the designs she produces I don't have anything to say about - they all are possible.

Are you saying designers that work on professional web site teams don't know about how web pages work?

Some don't :)

People really create pages in Photoshop for the design?

Every designer I've ever worked with has always used Photoshop for website designs (bar one design I've gotten in Fireworks) - maybe this is an Australian thing, I don't know, but I never cared what format it came in so long as I could turn layers off, and cut bits out, and have already discussed with the designer what may have a problem and may not be possible.

I myself, when I design websites (since I also do some designing) design in Photoshop mostly, though sometimes in Fireworks.

jessejump




msg:3164484
 3:15 am on Nov 22, 2006 (gmt 0)

I thought using Photoshop or Fireworks with slices and complex tables was highly discouraged among professional web organizations.Do people still do this?
Don't most pros even reject using Dreamweaver, etc.

How would someone mock up a site like this or Wired in PS?
I'm serious, I don't understand this.
Most great web sites use a few images along with some background images.

Setek




msg:3164494
 3:47 am on Nov 22, 2006 (gmt 0)

I thought using Photoshop or Fireworks with slices and complex tables was highly discouraged among professional web organizations.Do people still do this?

Are you talking about using a design in Photoshop, making slices, and using its automated generator to make the HTML code? Because yes, that is highly discouraged, anything that automatically generates code like this is bound to create bloated, bad code, but yes, I'm sure people still do this.

What I was referring to was merely people doing the design itself in a program such as Photoshop, then I would manually cut out the images I'd require, and code the HTML and CSS myself.

Don't most pros even reject using Dreamweaver, etc.

I still use Dreamweaver - it has nice code-completion (if you type <li> it chucks in </li> for you), and code-colouring.

It also has fairly nice find-and-replace functionality, being able to search for specific tags, with specific attributes, and changing the attribute value associated to it.

It depends on how you use Dreamweaver - if you use it in Design mode you're obviously using bloated HTML & CSS created by Dreamweaver, but if you use it to hand-code I don't see a problem.

piskie




msg:3164504
 4:07 am on Nov 22, 2006 (gmt 0)

I agree, I use DW on a 3 screen setup.

Design view on the Centre Screen, CSS (external Editor) on the Left Screen and HTML (DW Code View) on the Right Screen,

Very quick and very controlable producing neat trim code with a good productivity rate.

webdoctor




msg:3164629
 7:09 am on Nov 22, 2006 (gmt 0)

How would someone mock up a site (...) in PhotoShop?

I was recently involved in a site redesign, I was advising a company on technical issues but an outside firm was doing all the rest of the work (design and coding).

My client was provided with 12 'swatches' by the design firm - each of these was simply a .PNG image showing what the main page of the site would look like - each one had very different themes, fonts, layouts and so on.

The design firm didn't build 12 sites, they simply created the image file in Photoshop. Once the client had picked which one(s) they liked, the design firm then built the site to look like the image.

YMMV but I assumed this was a pretty standard approach. No point in creating 12 sites in full (html, images, css...) if you know in advance 11 of them will be rejected :-)

yuval_raz




msg:3164663
 7:56 am on Nov 22, 2006 (gmt 0)

well, for once not every market is the same...

ill give you an example.

spotlight on the Israeli web:
95% of browser market share goes to IE (first to implement RTL code in their browser), most people here don't even know that there are any other browsers. and those who do can't get them to load most of the Israeli sites (they break).

most designers here still haven't heard of standards and CSS.
my company is the only one in Israel who teaches standards based web design and coding (and we're not that big of a company).

which brings me to the point - most designers here are print oriented, and the web oriented ones are VERY expensive. (luck would have it we have 3 of them on our payroll).

every time I have to code a design made by external designers it's the same old story: "fluid what? standards who? other browsers where?"

just letting off steam i guess...

rocknbil




msg:3164867
 12:47 pm on Nov 22, 2006 (gmt 0)

I don't think it's so much that "some" designers don't know about the nuts and bolts of web construction - it's that they don't want to know. Controlled environment or something. <shrug>

webdoctor




msg:3164895
 1:01 pm on Nov 22, 2006 (gmt 0)

every time I have to code a design made by external designers it's the same old story: "fluid what? standards who? other browsers where?"

<tinfoilhat style="ON">If you're given a design which is essentially a screenshot, isn't it up to YOU to work out how to code it?</tinfoilhat>

IMHO the designers' job is to come up with the look-and-feel, the coders job is to make the actual pages fit this as closely as possible.

Or am I missing the point?

genem




msg:3164900
 1:17 pm on Nov 22, 2006 (gmt 0)

Speaking of coding, what do you think of using Yahoo's user interface grids (open source)? I will be facing a redisign too and I thought that that using tested sort of framework is a good idea.

ukDevelopments




msg:3164902
 1:18 pm on Nov 22, 2006 (gmt 0)

Hi thesheep.

I experience the issues you mention all the time.

These include full page height designs (a real pain in css!), over-lapping areas and areas of the page which are difficult to make editable due to the use of a CMS.

Setek




msg:3164904
 1:22 pm on Nov 22, 2006 (gmt 0)

<tinfoilhat style="ON">If you're given a design which is essentially a screenshot, isn't it up to YOU to work out how to code it?</tinfoilhat>

IMHO the designers' job is to come up with the look-and-feel, the coders job is to make the actual pages fit this as closely as possible.

Or am I missing the point?

I think the point is a little missed. Think of it this way:

  1. A client signs off on a quote;
  2. The designer makes a design;
  3. There is no input on possibility/problems by the developer, and the client signs off on that design;
  4. While developing, you encounter some problems whereby some things aren't possible. You now have to edit the design. The client's unhappy - they notice some parts are different to the original sign-off design - what's going on?
  5. Go back, go over the design with the designer, get the changes signed off - again - and then develop as necessary.

Bit of a waste of time, if you ask me. If you catch a problem while it's being created by a designer, you can save yourself a lot of effort in the long-run. A client signs off a design, you have to be sure you can produce that design. You don't want to go through the hassle of the project manager telling the client "Oh, yeah, you know that design? That's not actually possible. Yeah... so you'll have to sign this new document, because we think that one's possible."

The client won't be very happy with you changing things on them...

And before anyone says "yeah, but it's your job to make it happen" think about this - why is the design the crux of the website? Why is it placed as the penultimate hurdle? What if that design is unusable? What if it's inaccessible? What if it's SEO-unfriendly?

How important's the design then? It may look very pretty, but if nobody can use the site, it becomes useless.

And that's why it's important to go over with your designer during the design phase, about all the problems and things that could be done better.

yuval_raz




msg:3164978
 2:46 pm on Nov 22, 2006 (gmt 0)


<tinfoilhat style="ON">If you're given a design which is essentially a screenshot, isn't it up to YOU to work out how to code it?</tinfoilhat>

IMHO the designers' job is to come up with the look-and-feel, the coders job is to make the actual pages fit this as closely as possible.

you are right about one thing - if i am GIVEN a design i signed off. sure - I'll have to bite the bullet. but if i can have a discussion with the designer before the design is done, i can (and most often will) change the design to fit the coding.

problem is we are talking about two different things here.
my problem arises from the fact that designers here aren't aware of fluid designs and everything has to be pixel perfect.

most methods of web design that are common around the world are strange and unfamiliar territory to the Israeli market (even the universities still preach for the use of tables for layout).

my point: it's hard to do CSS in a TABLE state of mind.

Murdoch




msg:3165027
 3:26 pm on Nov 22, 2006 (gmt 0)

Every time someone argues with you about the look of a site, just tell them you can do everything in images and area maps. Then watch them cry as they never get indexed.

Normally as long as I can get a PSD file out of a designer I'm pretty set. It's the fonts that everyone always whines about (although with IE7 this has somewhat diminished)

webdoctor




msg:3165108
 4:23 pm on Nov 22, 2006 (gmt 0)

While developing, you encounter some problems whereby some things aren't possible. You now have to edit the design. The client's unhappy - they notice some parts are different to the original sign-off design - what's going on?

Ever heard of "managing expectations"?

IMHO there's a flaw in the methodology if you let a client sign off on a simple screenshot without pointing out that that's what you're *aiming* to produce in the final version, not what *will* be produced.

Why risk promising something you can't deliver? If you explain this up-front, there's much less risk of disappointment later on.

thesheep




msg:3165219
 5:22 pm on Nov 22, 2006 (gmt 0)

Chip - what you are saying is that as coders we should be able to take any design thrown at us and code it up - if not then our own coding skills are not up to scratch.

I think there is merit in what you say, in the sense that taking on a challenge can stretch us and often solutions can be found to a problem that seems impossible at first.

However, I think there are some design structures that really are better avoided.

Take, for example, the following type of layout:

An overall 3 column layout. Within this there is a central flexi-width column that contains a further 3 vertical columns with borders and background images that overlap between columns. The columns must be flexible width and always be in exactly the same 33% ratio. The text must be resizable and the layout must not break within 2 increases of text size. The columns must allow for different amounts of textual content but must always be the same height as each other.

Having tried to build things like this, I find that the results are never perfect and the result is a lot of non-semantic markup and CSS hacks. It can also take a very long time to produce and debug.

It may be that my coding skills are not up to scratch (and I freely admit that there are more experienced and knowledgeable CSS coders than myself, quite a few using these forums). But looking around, I don't see these kinds of layout on the web today.

Aside from this, for me the real beauty of web design is to work with the constraints of the media (in this case XHTML/CSS) and produce pages that have both visual appeal and are as robust, well-structured and maintainable as possible.

jgstyle




msg:3165327
 6:40 pm on Nov 22, 2006 (gmt 0)

Ever heard of "managing expectations"?

IMHO there's a flaw in the methodology if you let a client sign off on a simple screenshot without pointing out that that's what you're *aiming* to produce in the final version, not what *will* be produced.

Why risk promising something you can't deliver? If you explain this up-front, there's much less risk of disappointment later on.

You're right, there IS a flaw in this methodology. But I think he's talking about situations where you have no say in what the client sees and signs off on.

I have that exact problem with my boss. He'll produce these visually stunning designs for the client that are very difficult, if not impossible to pull off on the web.

I've asked him to please let me see his designs before he shows them to the client, or to at least tell the client that this is a "more or less" vision of how the site will look. However, he does not do this, and as he is my boss, I'm not in the position to force this to happen.

Of course, what I end up having to code in is a bunch of wacky fonts and drop shadows and ridiculously large background images and pictures that really serve no purpose. The pages are unnecessarily heavy.

One of his favorite designs is some sort of frozen horizontal bar design that confines paragraphs and paragraphs of text to a small square in a scrolling window. It's a very cramped feeling and nothing is liquid in these sites so the user has verry little control or recourse to view the site as they might wish.

These designs also hamper our ability to update the site efficiently and easily. New products and pages are usually a hassle to to the navigation scheme.

I've tracked all my wasted time in an attempt to gain some sort of inclusion into the design process. To no avail. Sometimes I feel embarrassed for our studio and bad for most of our clients, but I guess I shouldn't since they seem happy with what they get.

Oh well, this is a frustrating experience but I can see I don't go through it alone.

vincevincevince




msg:3165764
 3:55 am on Nov 23, 2006 (gmt 0)

I think that there is much to be said for not letting coders get involved with design. The only exception is for SEO, in which case the designers need to be told certain things which don't work from an SEO perspective (non-standard fonts which would need to be images, fancy flash navigation... etc.)

An overall 3 column layout. Within this there is a central flexi-width column that contains a further 3 vertical columns with borders and background images that overlap between columns. The columns must be flexible width and always be in exactly the same 33% ratio. The text must be resizable and the layout must not break within 2 increases of text size. The columns must allow for different amounts of textual content but must always be the same height as each other.

Nested tables comes to mind, with CSS relative positioning for the overlapping backgrounds.

<table><tr>
<td width="100">1st main</td>
<td>
.<table><tr>
..<td width="33%">Ratio1</td>
..<td width="33%">Ratio2</td>
..<td width="33%">Ratio3</td>
.</td></table>
<td width="100">1st main</td>
</tr></table>

Setek




msg:3165773
 4:02 am on Nov 23, 2006 (gmt 0)

Nested tables comes to mind, with CSS relative positioning for the overlapping backgrounds.

Yeah, beautiful way of just 'getting the job done'.

But how fast can you say (and have somebody understand):

Table with one column and three rows.
1st main
Table with three columns and one row.
Ratio1
Ratio2
Ratio3
Table end.
1st main
Table end.

The thought's not very appealing...

:)

[edit]

You know what, while I'm at it, have you ever tried printing nicely laid out pages like that?

I hate it when people always say to me "don't knock tabled layouts until your CSS-P can do everything a tabled layout can."

Can you hear a tabled layout easily? Can you print a tabled layout nicely? Can you see a tabled layout on a small screen? How about change a setting on a particular cell for all pages?

I'm sick of it. How about "don't say 'don't knock on tabled layouts until your CSS-P can do everything a tabled layout can' until a tabled layout can do everything CSS-P can."

... yeah... end of gripe... sorry :)

[/edit]

[edited by: Setek at 4:10 am (utc) on Nov. 23, 2006]

vincevincevince




msg:3165806
 5:14 am on Nov 23, 2006 (gmt 0)

Can you hear a tabled layout easily? Can you print a tabled layout nicely? Can you see a tabled layout on a small screen? How about change a setting on a particular cell for all pages?

When a design is described so specifically by the designer then it is not going to print nicely or read nicely as a table or using CSS-P. I'm a big fan of CSS and CSS-P and use it on almost everything I do. I suggested tables not because CSS-P couldn't handle it, but because it would take much more work to implement - and from the prescriptive strangeness of the design I reckon that accessibility and printability aren't on the priority list.

Incidentally - using a print CSS sheet and setting:
tr {display:block;float:left;width:auto}
td {display:block;float:left;width:auto}

Makes a good estimate to printable.

This 37 message thread spans 2 pages: 37 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved