I am tasked with updating a family of web sites that promote scientific conferences that cater to a niche scientific field. The sites are currently written with some modest CSS layout for the shared common page template structure, but the details of each page are a mishmash of <p>, <br>, and to position the content. This makes it tough to update the content, since the spacings are always changing, and the page ends up ugly at the slightest mod.
So, I'd like to change this stuff into a more CSS-happy state. There are lots of sites that offer tips for specific CSS design goals, but I'm a developer without a lot of web site artistry capabilities and don't have a structure already in mind. Are there any good sites that teach CSS in the context of some relatively mundane -- but effectively presented -- business content? Stuff like the CSS zen garden is way cool, but I'm looking more for something that will both give me some simple text-heavy business data positioning ideas and present those ideas as a CSS learning opportunity.
Does any such site exist?
Sadly, if you don't have much control over the HTML, it's hard to get a solid, consistent presentation out of CSS. This is especially true if you're not able to add special classes/IDs to your elements. And <br/> tags, incosistently used, will wreak havoc with any attempt to standardize the layout.
If you're only limited to the HTML you've been provided, you're primary goal should be to make it as readable as possible. Make sure the font size is large enough that people can comfortably read it leaning back in a chair. Or standing over someone's shoulder. It doesn't need to be too big, but if it's text heavy like you claim, traditional 12pt might feel too small for a lot of reading.
Which font to use is another consideration. Verdana is wider than Arial, so it takes up more horizontal space, but tends to be easier on the eyes. Others tend to prefer a serifed font like Georgia, which can hold up well at larger sizes.
Vertical spacing is important. Make sure to include plenty of visual break-age between areas of the page. You can achieve this with an obvious and consistent subheading style. Also make sure that the line-height between each line is wide enough - people don't like to read 'bricks' of text.
And don't forget horizontal space. A general rule of thumb is that a column of text probably shouldn't span more than 60-70 character per line, or it becomes more difficult read.
Remember that people are coming to your site for information, and the quicker they can access and get that information the happier they'll be. Visual eye candy is nice, but your first priority should always be make the site as easy to use and legible as possible.
As for inspiration, I'm a pretty big fan of the text design over at Information Architects. You may also want to have a look at Subtraction.com. Blogs will probably be a good source of inspiration, as they're typically very text heavy.
Good luck.
I'd say A List Apart is a good place to start.
You can choose from a very broad (and structured) range of topics and then follow the related links from a subject that you find interesting.
I had a similar situation and learnt a lot by downloading and studying some of the designs at http://www.openwebdesign.org/ . There are a ton of designs and the forums are full of people willing to help.
Eric Meyer is always a good CSS resource.
First things first. Use simple and semantic XHTML. If applicable, ditch those <br>s for <p></p>s. Use <h1>,<h2>,<h3>, etc consistently. You know you're on the right track if your page looks clean and readable without a reference to the CSS file. David Shea has a great markup guide.
David Shea's Markup Guide
As for style guidelines... I like Ben Hunt's Web Design From Scratch even though he pimps his eBooks incessantly. The content is good.
Web Design From Scratch: Style Guide
Web Design From Scratch: Current Styles
If you are looking for sample ASP.net sites with a bent towards proper CSS check out Microsoft's free templates.
ASP.net Design Starter Kits
Finally, and this is a real gem here, if you need to style tabular data, Smashing Magazine has the goods. These table designs are off the charts. Sample code included. Actually, you could spend hours on the Smashing Mag site. So many great examples and free stuff.
Smashing Magazine: Top 10 CSS Table Designs
Smashing Magazine: All CSS Articles
peace|dewde
Battle of the CSS Frameworks is another good resource to start with. You might be able to cut your CSS development time down by adopting a good, simplifying framework.
Related
What is the point of these CSS Frameworks? I don't understand them. When I look at them, all I see is boring layouts that seem overbearingly-difficult to adapt to your own unique designs.
Is this the case, or am I just missing something here? I'm referring to (frameworks in general) things like Blueprint, Less, Skeleton, 960 Grid system, Base, Gridless, etc etc etc.
I know this is a really simple thing but I just don't get it. I have searched but have not found anything that helps me to understand what the big deal is. When I look at their code, all I see is mess. Weird class and id names all over the place.
(This isn't a rant or complaint by the way, I just really don't get it.)
CSS frameworks are pre-prepared software frameworks that are meant to
allow for easier, more standards-compliant web design using the
Cascading Style Sheets language. Most of these frameworks contain at
least a grid. More functional frameworks also come with more features
and additional JavaScript based functions, but mostly design
orientated and unobtrusive. This differentiates these from functional
and full JavaScript frameworks. -Wikipedia
Advantages
They can help you learn CSS. You might just literally not know how to pull off a solid multi-column layout. A framework may be a
good place to get your feet wet understanding how CSS works.
They provide code that you just don't need to write from scratch every time, like resets. I've long been a proponent that the star
selector (*) margin/padding reset is a fine reset. I use it all the
time. But... if you are starting a major new project that is going
to be loads of pages, live for years and years, and will grow over
time, you should invest right away in a more robust reset. All
these frameworks start with brilliant resets that cover all the
bases and will have you covered for years to come.
They relieve cross-browser concerns. You can't undervalue this. We've all felt the burn of finding out our sites are borked
in some browser or another at a hugely inopportune time. Frameworks
are built to bring their magic to all browsers.
It helps you build good habits. Like including a print stylesheet in your projects. I always intend to build one, and I
often do, but the chances are a lot higher that I do it if I have
one there from the get-go.
They encourage grid based design. Which is a good thing. Grids don't mean boring! They just help you achieve better
readability, scanability, balance visual weight, flexibity,
expandability, and just overall page page cohesiveness.
They come with documentation. If you need help getting started, framework generally come with some support files. This can be
particularly nice if you are designing a site you will be handing
off to a client. You can just let them know what framework you used
and refer them to that documentation for support requests.
They lay groundwork. If you are using something like YUI, your life will be a lot easier if you use All-YUI-Stuff-All-The-Time.
It's built to work together and built for expandability.
CSS-Tricks
Also see: Comparison of CSS frameworks
I know that is a very embracing question, but I have just started with Ruby on Rails, and still have a long way with CSS and HTML.
There are lots of books about CSS and HTML patterns, but I would like to know what is really applied to actual webpages.
For example, what's the best way of doing a simple webpage with a lateral menu, a logo on the top, and some text below?
Ok, it seems stupid, but there's lot of ways of doing that, or not ?
So, how can I learn this patterns and what are the real patterns ?
Would appreciate suggestions of books, articles, etc.
you can find some good css templates here:
http://www.csszengarden.com/
Actually in html and css there are not patterns in the oo sense.
I find this tutorial very useful:
Design and Code your first website
The nettuts website has a lot af very good free tutorials.
A very good book to begin is:
Head First HTML with CSS and XHTML
It varies from developer to developer. So I'll just tell you what I'm doing!
I'm actually following a very common pattern - separate ANY layout from the contents!
Into the HTML goes...
Text
<div/> containers with IDs to be layouted
And in the CSS goes...
Layout for the ID'd and class'ed <div/> layout containers
Colors, Background images
Fonts
It allows to rapidly change the whole page design without even touching the HTML! And it decreases both your server's traffic and the load time on the client pages, because the CSS file can be cached, since it does not change as much as the HTML does!
The CSS Zengarden nate posted is a very nice example of this pattern. The same unmodified HTML with dozens of CSS files with totally different looks!
This pattern also allows the same unmodified HTML to be displayed with automatically selected CSS files on huge displays, on small netbooks and on mobile devices. Can't be any better if you ask me!
You might want to check out some CSS libraries.
I don't personally like using them because I have ways that I like to do things and sometimes they aren't flexible enough for what I want to do. But since you're just starting out they might help you get something that looks good up really fast without having to worry about float drop bugs or margin collapsing or any other CSS quirks that are easy to hit but hard to recognize if you haven't seen them before.
An example would be the Yahoo User Interface (YUI) Grids CSS that will help you set up many different kinds of grid layouts. To find more, I would search for "css framework" or "css library".
Another YUI resource I think would be really useful for you would be their design pattern library, which documents different ways to display common interface items and gives you resources to go implement them. This can help make your interface look familiar to users and can keep you from feeling like you have to redesign a drop-down box or something.
The rule of thumb should be to do all design in CSS and HTML is just HTML without calls to design. That way, like referenced above, you can change design rapidly.
A good reference for how this works is the Zengarden CSS site at: http://www.csszengarden.com/
This is a site I used often as I learned the ins and outs of CSS design.
Let me begin this topic by explaining my background experience with web design. I have always been more of a back end programmer, with PHP and SQL and things. However I do have a shallow background with HTML and CSS. The problem is, I don't know it all. What I do know is, when it comes to designing (not back end dirty work) I understand basic CSS properties and I also understand HTML and I can usually throw together a sloppy web page with the two and a couple bazillion DIV tags.
Anyways..
The problem I always have encountered is that when I design a website in a browser such as IE7 (and then it looks perfect on IE7), and then look at it on IE8 or IE6 or Mozilla (etc.) it gets all spacey and ugly and looks totally different than the way it should look on IE7.
Question one:
Basically, what I am asking everyone is what route should I take to learn how to properly build the website? Build as in put it togehter with CSS standards and HTML standards that will make my site look the same on every brwoser. (Not only learning standards but where can I learn to properly write my code?) Where is a strong free resource I can use to learn how to these things?
Question two:
How do I properly code my website? Do I use all external style sheets to make dynamic page design simplistic or do I hard code some things into the DIV tags on each page? What is proper?
Oh, and if anyone has any tutorials on how to properly design a complete layout feel free to throw it in a response somewhere.
Thank you for taking the time to read my questions, and hopefully you will understand what I am trying to get out to everyone. I need to get on the right route of the designing side of web programming so that I will know how to create successful websites in the future.
Thank you,
Sam Pardee
First, I recommend NOT starting with IE as your "development" browser. Start in Firefox, say (which gives you the advantage of tools such as Firebug and the web developer toolbar), and then get it right in IE afterwards.
Second, definitely user external style sheets; it results in much cleaner code and a much simpler way to make style updates. Definitely recommended. Also external CSS files can be cached by the browser, so they won't increase the page download size as users go from page to page in your site or application.
Lastly, start by defining your content using simple HTML, basing the structure on the meaning of the content (often called "semantic" HTML), not on how you want it to look. Use a <ul> tag for something that is a list of items, for example, even if you don't want to display it as a "bullet list" (the default styling for <ul>). Then start adding styles to make it look right. This will result in very clean HTML that can support a variety of formats and layouts (take a look at CSS Zen Garden to see what I mean) and will also help push you towards a layout that reflects the structure of your content, which will be easier to read and comprehend.
In terms of books, you can't go wrong with Eric Meyer. HTML is easy, of course, and I don't recommend doing fancy stuff with HTML, so put your learning effort into CSS (Eric is the CSS guru).
Cross-browser compatibility is always an issue. It's a staple of web development, sadly, and there is no magic bullet. Luckily, the main offender, IE6, is finally starting to fade.
A1.
When starting work on a new site, first take every piece of content that needs to be on the page and paste it into a text file. Then put it in a rational order (thinking "If I had to use a text browser to use this page, how would I want it to be arranged...").
Then start wrapping HTML tags around each piece of content. For each piece, think "What type of information is this?" A heading? h1/h2/etc tags. A paragraph? A quote? A table? p,quote,table. Essentially, use HTML tags that describe what kind of information each piece of content is. When I do this, I pay no attention to how it actually looks in the browser at this point.
Once the content is all marked up, begin writing the CSS. If at all possible, try not to touch the markup during this step. Sometimes that isn't possible, though, and throwing a div or span around some elements is unavoidable. The less meaningless markup, the better.
In my experience, this approach keeps things very clean and tidy, and makes debugging layout issues a lot easier.
A2.
Building the styles into your markup using the "style" attribute is fine for prototyping, but beware, the temptation to leave them there once it works is strong. The best practice is to have all of your styles in external stylesheets. I'm interested to hear any alternative viewpoints.
Some great web standards/CSS resources:
http://www.csszengarden.com/
http://www.alistapart.com/
http://www.thenoodleincident.com/
http://www.quirksmode.org/css/contents.html (useful reference for selector-compatibility)
http://centricle.com/ref/css/filters/ (good reference for css hack compatibility)
http://www.zeldman.com/
http://meyerweb.com/
Hope this helps!
There are TOO many site out there that have really great tutorials for HTML and CSS. They will give you all of the information you are asking for. I would start doing some reading of the great gurus of HTML/CSS:
Simon Collison
Andy Budd
Molly Holschzag
Dan Cederholm
Jason Santa Maria
Eric Meyer
Jeffrey Zeldman
Cameron Moll
Any book or article you can fond from these folks will steer you in the right direction; you can't go wrong!
As for sites that will give you the proper methods/concepts/training for web standards compliant sites:
http://www.w3schools.com/default.asp
http://www.webstandards.org/
http://www.smashingmagazine.com/
http://www.webdesignpractices.com/
http://www.designmeltdown.com/default.aspx
http://www.cameronmoll.com/
http://www.alistapart.com/
http://www.cssnewbie.com/
http://www.css3.com/
http://htmldog.com/
http://css-tricks.com/
http://simplebits.com/
http://www.colly.com/
http://glish.com/css/#tutorials
http://meyerweb.com/
http://jasonsantamaria.com/
The one of the best books I've bought so far to help with HTML and CSS coding PROPERLY is Beginning CSS Web Development by Simon Collison. Great, easy to understand, and not too slow. Great examples to follow along. After that, buy CSS Mastery - Advanced Web Standards Solutions, also by Simon Collison, and Andy Budd and Cameron Moll. This book gets you up to speed with some advanced techniques that you'll see on the many of the web sites right now, some of which were invented by the authors.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
At work I see one colleague designing a site in Photoshop/Fireworks, I see another taking this data, slicing it up and using Dreamweaver to rebuild the same from scratch.
It seems like too much mucking around!
I know that Photoshop can output a tables based HTML, and Fireworks will create divs with absolute positioning; neither appear to be very helpful.
Admittedly, I haven't tried much of (DW/FW) (CS4/CS3) since becoming a programmer, so I don't know if new versions are addressing this work flow issue, but are we still double handling things?
Can we attach some sort of layout metadata (this is a rollover button, this will be a SWF, this will be text, this logo will hide "xyz" <h1> text etc) to slices to aid in layout generation? are there some secret tools which assist in this conversion process? Or are we still restricted to doing things by hand?
The frustration continues when said hand built page needs to be reworked again to fit Smarty Templates/Wordpress/generic CMS.
I acknowledge that designers need to be free of systems to be able to do whatever, but most conventional sites have:
a header with navigation
a sidebar with more links
the main content part
maybe another sidebar
a footer
Given the similarity of a lot of components, shouldn't there be a more systematic approach to going from sliced designs to functional HTML?
Or am I over-simplifying things?
-edit-
Mmmmm.... I suppose I will accept an answer, but they weren't really what I was looking for.
It just seems like designing the DOM is a bit of holy grail ("It's only a model!"), and maybe with all the "groovy" things you can do with HTML and Javascript, it would be mighty hard work, but with a set of constraints (that 960 stuff looks interesting), some well designed reset style sheets and a bit of... fairy dust? we should be able to improve the work flow.
Photoshop's tables by themselves are pretty much useless, I agree, but surely we can take this data, and then select a group of cells and say "right, this is a text div, overflow:auto" or "these cells are an image block, style it with the same height/width as the selected area". Admittedly here at work there are other elephants in the room that need to make their formal introductions to management, but some parts of the design>page workflow seem... uneducated at best.
To me, doing it by hand is an advantage. You only have to get it right once, and if you're going specifically for visual appeal, you've likely got a lot of work ahead of you making it cross-browser friendly...
Would love to hear other answers. This is just my take on it as I make more data-driven than visually appealing sites.
Skip Photoshop entirely and just get your designers mocking up straight in the view HTML. Not only will you remove the complicated, awkward-feeling process you're feeling, but you'll get better, more resilient designs, because 100% of it will be based on what's possible in HTML/CSS, not what's possible in Photoshop.
More reading:
Why We Skip Photoshop
(37signals)
Walls Come Tumbling Down (Andy
Clarke) (via Jason Berry's
answer)
Web Designers Should Do Their Own
HTML/CSS (37signals) (via Paul
Souders' answer)
A number of people nowadays are designing straight into the browser using (X)HTML/CSS because of that exact problem - all of the mucking around with Photoshop and then going to code after getting the client to sign-off on a static design.
A good read is Andy Clarke's Walls Come Tumbling Down presentation.
Omega touched on it, but I think the biggest problem is cross-browser compatibility. If all those browser quirks didn't exist (coughInternetExplorercough), what you suggested would be much simpler. However, it often takes a lot of hand-coding to make it look pixel-perfect in every browser.
Another thing is fine-grained control. Sure, you can just pop your PSD template into Dreamweaver or whatnot and have a working website, but it's going to use hacks and ugly things like tables to make it work. And even then, it probably won't work entirely like you want it to. You have to remember things like accessibility and SEO, too, and Dreamweaver just can't give you that.
My opinion is that HTML/CSS is sufficiently simple that a competent web designer should be moderately fluent in it. Photoshop has its place for quick look-and-feel experiments, but I think this misses an important step: user experience design.
Personally, I've been designing and prototyping directly in HTML for some time now. This is where the clean separation of content and layout provided by CSS really shines. I organize pages into regions using unstyled divs, which allows me to organize the page conceptually (i.e. keep related items near each other in the code) and postpone thinking about appearance. This has the side effect of making a pretty thorough site inventory.
Next I'll use CSS to lay out the divs, which happily also produces wireframes (useful for reviews and paper prototyping.)
The last step is applying visual elements: color, text styles, graphics. I'll use whatever graphic program I need to cook up the pretty.
Note the orthogonality inherent in this method: develop concepts, then layout, then look and feel. This puts the hard thinking (conceptual models) up front, and the most volatile thinking (colors/styles) at the end. So when the art director changes the color palette, you only have to edit one CSS file. And if you need to change your conceptual model, much of the layout and look/feel may be reusable.
If you need traction in this method you can use a standard css grid like 960 (http://960.gs/). It handles a lot of the arithmetic and floaty business that makes layout such a chore.
In addition to Rahul's link above I also recommend: http://www.37signals.com/svn/posts/1066-web-designers-should-do-their-own-htmlcss
It's a nice pie-in-the-sky sorta dream, but I think as long as websites are written in (X)HTML/CSS, at the end of the day, you'll always have to do some, most or all of the work manually.
There's just a fundamental rift between static pixels in some 'shopping software and dynamic, changing, expanding, content-focused, text-based sites. The best tool to bridge that gap is still... the human professional.
Tools like iWeb (completely WYSIWYG) or DW/Fireworks (somewhere in the middle) only get you so far or have serious limitations. You get only pre-fabbed templates in case of iWeb, often sub-optimal code in case of DW/Fireworks. You'll have to decide which limitations you can live with and when it's best to do it manually.
There are several tools such as Sitegrinder that do just that.
Adobe themselves has a project in Labs called Catalyst that does what you describe and more for Flash:
It takes the slices from Photoshop, allows you to change their properties and export it to a working Flash file. (Right click box, add text property, it becomes a text field...)
If you watch their video (which you should - its amazing), you will see that they are deluded into thinking that websites will soon be built this way.
Before Zimbra was bought by Yahoo, it looked like they were heading towards such a tool that outputted cross-platform HTML similar to what catalyst does for flash. No more. But with the shake-ups at Yahoo, such software may still rise from the Zimbra ashes.
In my opinion, a site should be mocked up in Photoshop if necessary, with parts being cut out for use in the actual site, but to design the site completely in Photoshop, then want to make it work on the web is just going about it backwards. Really the two should be done in parallel.
In short, graphic designers design the look of a website, but you need a programmer to program it.
What you probably should go for is train the designers to work within a well established grid system for their site designs. If they can understand the layout as a grid/block system a lot of interesting design can be accomplished within those constraints. But it isn't going to be straight conversion from PSD to HTML because they are two completely different ways of representing visual data.
There are lots of frameworks that make the css work easier. One is Blueprint CSS
http://www.blueprintcss.org/
There are lots of templates out there for representing the grid system within photoshop.
http://konigi.com/tools/photoshop-template-blueprint-css-comps
Think of the grid as a visual constraints layer, then the design can be mapped between a photoshop comp and specific HTML/CSS implementation. Visual elements have to be bounded within clean grid boxes. SOme elements or units within the grid can be mapped to background images. Others solid colors or white space with div containers holding content.
With a well understood and grid framework you can get pretty close to pixel perfect layouts.
Also, good designers will understand how to use white space effectively in a design mockup. If there is lots weird intersecting lines and crossover elements in the visual design then that presents a real challenge for implementation. Just because you can visually imagine it doesn't mean it is easy to implement in a browser without making certain kinds of trade offs for the way HTML and CSS work. Think of the grid system as the constraints and an effective way to judge layout requirements.
Personally, I design it in html/css first using borders and background colors. I then take the PSD and insert the images as background images or html images. It's pretty fast, the code is yours so you know what each css rule mean which speed up the dev process (as opposed to to PS's awkward sliced image names and css selectors names)
I'm trying to compile a guide for students used to publishing in print who are learning web design.
Some obvious things which web developers know but they don't:
You can't rotate graphics in HTML
All objects have to be rectangular, you can't have a circular DIV
Many typographical effects in their repertoire can't be achieved
Some things which are tricky are:
Can they have variable opacity? Well, yes and no.
Can they have rounded corners? Maybe.
Some things which aren't technical difficulties, but which are problems:
Image file sizes: I have a student who wants to have a different large graphic header on every page of their site; that's not technically a problem, but it will mean a visitor has to wait for a new graphic to load every time they navigate
Accessibility: "why not just make everything a graphic, to overcome the limitations of HTML?"
Please help me fill out my list and add any hints or tips for people making this transition.
web is not print
Layouts can be fluid.
elements don't have to be absolutely positioned
web pages need to be checked in several browsers for compatibility
avoid divitis; from experience people coming from print into this field do everything by brute force instead of trying to think of elegant solutions for optimization and semantics purposes
print is consumed visually - the web is consumed by people with visual impairments as well. Don't forget lynx users no matter how small the market share is :)
semantics is important, learn about them
thats all i can think of right now...
Coming from someone who has done both print design and web design (and done a decent job at both, I think), it seems like you're off to a good start. Other thoughts:
Darko Z mentioned this but I think it's worth stressing that browser incompatbilities must be recognized and dealt with. In the print industry there are standard formats like PDF which guarantee that things will come out in print the way they look in design; besides, many publishers will directly accept the native file formats of the most popular design programs, like Adobe InDesign, Quark XPress, even MS Word (for the cheapskates ;-P). The point being that print designers are used to a "set it and forget it" approach where they assume that once they design something a certain way, it will stay designed. The fact that there are different web browsers which render the same web pages slightly differently is likely going to be a major pain in the butt for people used to the print world.
Addendum to the above: fonts. You can't use (or at least can't rely on) uncommon fonts in web design, for obvious reasons.
Screen real estate has to be used effectively because there's a limited amount of it. And I mean really limited - no matter how hard you try, you can't write HTML that will make someone's monitor expand 5 inches or put another screen on the back ;-) It's not like in print where people can peek back and forth between different pages of a book. Reading web pages is kind of like looking at parchment through binoculars; you have to design the pages with that limited field of view in mind.
Web page designs are dynamic and transient; they stay up for a while, they get boring, they get recycled/replaced with new designs. So you're not stuck with mistakes. But it also means you need to design with future changes in mind, e.g. by using CSS so you can change the look of whole classes of elements easily. There is some use of styles in print design but nowhere near as much as online.
Fonts and Text
You are limited to a small subset of
fonts
Fonts are viewed at different sizes
There is a readability limit for how
wide paragraphs should stretch (in a
fluid layout)
Write for readers of all types - Some
will skim, others will read in detail
Images
Sites are viewed at different
resolutions and screen sizes - Design accordingly
To achieve transparent backgrounds in
IE6, use PNG8 with alpha (IE6 doesn't
support varying levels of
transparency, it's either 100%
transparent or it's opaque)
Use CSS sprites
Images should not be used in place most of text
The img tag should be used for images
with semantic value and all layout
images should be CSS images
Every img tag needs to have the alt
attribute to validate
(X)HTML and CSS
Browser rendering varies greatly
Validate CSS and (X)HTML for a
greater probability that the design
will be cross-browser friendly
Don't use CSS hacks
Use the proper semantic markup
Pages should be able to work without
JavaScript enabled
Read Yahoo's guide for
performance and use YSlow
Dreamweaver's design mode doesn't
reflect how a page will appear in
real browsers
General Design
Simpler is often better in terms of
usability, accessibility, design, and
download size
Lists of greater than five or six
items should be broken up visually
Consistency is important - Don't
change your navigation, etc without
an extremely good reason
When choosing colors, keep those with
color-blindness in mind. This will
affect how you choose to convey
meaning by color.
Place the most important information
above the fold (the part of the
screen that shows without scrolling)
The web is interactive. This
drastically affects how you consume
and display information. You can hide and subsequently display information using tabs, accordion, and similar methods.
Think in terms of primary and
secondary calls of action. What do
you want the user to do? Where do you
want them to go next?
Some broad points:
1. Print is static, the web is interactive.
The essence of a print project is a fixed point in time, an idea captured on paper or some other substrate. Web projects are moving, changing experiences that represent both the ideas of their creators and their users.
2. Everything is uncertain.
You mention typography in your answer, it's probably worth broadening that to cover all aspects of appearance. The variety of operating systems and hardware available mean that its hard to determine how all your audience will experience your final design. Whilst some things must be compatible across all browsers, sometimes it is not worth the time and effort needed to make something pixel perfect in all systems.
3. Learn about programming.
Unless you've an aptitude for it, you don't need to learn how to program for the web. But it would still be a big help to gain some familiarity with web programming, as if you can't code, you'll need to work closely with someone who can and you need to be able to communicate effectively with them.
4. Create working prototypes
When something is static, it can be designed using a static format. To design something interactive like a website, you should be making use of moving prototypes that represent the kind of behaviour the final design will have. You can use paper to do this, or more sophisticated mockups using xhtml, css and javascript, or a dedicated prototyping program.
The user controls how they want to see content on the web, not you. Your design will not look the same to all people because some people may make it different on purpose.
Screens can be arbitrarily large or small
The web is interactive: usability trumps pretty-lookingness
Your page will be read by machines: make sure the data is easy to get at by scripts that can't read images / large blobs of text (aka "be semantic")
Remember to save your jpg files in RGB format not CMYK format. I regularly get sent jpgs that won't display on a web-site and every time it's because it's been saved in the wrong format from Photoshop.
This will become less of a problem as browsers support more image formats, but considering that 20%+ of users are still on IE6 for the sites we develop this will take a while to go away.
A lot of these are good rules of thumb for print designers who want to learn how to actually markup HTML and write CSS. But as a Web developer in the past, I'd frequently just take a designer's template and write the HTML and CSS for them. Whether or not that task was simple or difficult depended on the designer's awareness of the capabilities of CSS.
There was one pain point in particular that kept coming up. So for print designers moving to the web, the absolute number one rule to remember is:
Don't design any element to have an explicit, pixel-perfect height. You can restrict the width all you want, but changing fonts, preferred font sizes, and different text strings being pulled from the database on different pages means that text needs to be able to flow vertically without generating hideous, hard-to-use overflow scrollbars.
Designers who remember this can usually conjure up designs that are easy to cut up and integrate in a mostly semantic manner. Designers who forget this sometimes end up creating designs that have to be shoehorned into a 3 inch by 3 inch box, and that's when I reach for the vodka.
A given color or font will render differently in different browsers.
Especially when one browser is on Windows and the other is on Mac or Linux, etc.
I wrote a blog post about this a while ago - http://aloestudios.com/2008/08/dear-print-designer-doing-web-design/
So did my friend Mark - http://www.visual28.com/articles/tips-for-better-web-design
Jeffery Zeldman's book Taking Your Talent to the Web is specifically targeted to the question you have asked. It's been out for a few years...not sure if there's a 2nd or 3rd edition. Check it out.
My main advise is that you need to recognize that while you have dot precision in print applications, most of the time in web design your focus is to design and code a site that will accomplish your content and layout goals for any number of platforms, resolutions and color depths. Color depth has become less important than it was in the past.