Creating web site from TIFs using ImageReady or Fireworks?

June 13, 2005 6:56 AM

I offered to help a professional photographer friend make his web site, but I don't normally do it like THIS: He is a Photoshop wizard and has created how he wants his pages to look using that. He gave me a CD full of pages as TIFs. Is there a quick/easy way to make sites from TIFs using ImageReady or Fireworks? Pointers, links, tutorials, ect. GREATLY appreciated. (I realize that this does not result in the optimal site, but the guy wants it to look like he wants it to look).

(Not finding what I'm looking for with Google, for some reason.)

posted by spock to computers & internet (12 comments total)

Briefly: divide the images into logical parts using the Slice Tool (K). The sliced up image can then be exported as an HTML file (File->Save for Web...) consisting of tables filled with the appropriate images. For example, if his design has a beveled box with a bunch of text in it, you'll want to create slice rectangles for the border around the box. Then, once it's exported, bring it into Dreamweaver (or whatever editor) and remove the image from the center area between the borders and fill it in with the text.

More info: http://www.adobe.com/education/webtech/CS/unit_graphics2/si_create.htm
posted by tumult at 7:08 AM on June 13, 2005

In my experience, it is pretty common for designers to do mockups of websites in Photoshop. I'm curious about what makes it too onerous to you to translate his layouts into HTML/CSS.
posted by redfoxtail at 7:26 AM on June 13, 2005

The problem is not making mockups in Photoshop. The problem is not understanding that a web page is more than a big image sliced up and delivered in a table. Take a look at most of these sites (created in this way) and you will probably see what I mean. There is no text for Google to index, no ALT tags, no META tag keywords or descriptions, ect. They have a site that LOOKS beautiful (because it is virtually nothing but a big jpeg) but it isn't terribly effective. (Don't even get me started on the ones that use insecure pages to email credit card information via a CGI script- that's a way separate issue).
posted by spock at 7:39 AM on June 13, 2005

FYI: your link in the previous post goes to this page.

Can't you just take one page, slice it up and create the layout, then tell Mr. Photographer to send you a CD with the just pictures? If you mean that every page is laid out differently, then it's your job to tell him that that's the wrong approach.
posted by planetkyoto at 8:12 AM on June 13, 2005

if it helps, you can tell him that the customer is always right, however, the customer is not him but rather the potential clients who will be visiting his site, some of them downloading his pages by modem.
posted by planetkyoto at 8:21 AM on June 13, 2005

Sorry: Here is the corrected link of ImageReady sites:
http://www.marathonpress.com/page.php/mpi/marathon_sites.
posted by spock at 8:23 AM on June 13, 2005

If you are going to take this approach at all, make sure to closely optimize every slice from a GIF/number of colors/dithering approach or JPG/amount of compression approach or "Text" slice approach, depending on the underlying content.

Though Imageready->HTML may not be an aesthetically acceptable path for some, part of the overall issue is that people don't bother at all to optimize images before saving, meaning that you have an image-intensive layout that takes several times longer than necessary to load.
posted by VulcanMike at 8:34 AM on June 13, 2005

I usually build out pages the way you describe. Without seeing the files in question, it's hard to say, but I would guess that you can use ImageReady as tumult describes, and then selectively replace the texty bits with nested tables containing actual text, with background image if necessary. It is a fair amount of work. If you slice and dice carefully, you can also replace a lot of solid color background bits either by letting page bgcolor show through or by using a 1x1 gif that you resize/recycle into all the appropriate holes. ImageReady (at least the CS version; not sure about earlier version) will also export your slices as CSS using absolute position to position everything. I'm trying to learn to deal with that now. Here's an example of what I'm talking about.

One small tip: You'll find that for most images, GIFs will work better with VulcanMike's approach (which I agree with). Use as many colors as you need, but no more. Dither if you must but try not to. The challenge will be to get smooth color transitions from each slice to its adjacent slices. Sometimes it helps to optimize the whole page at 8 or 16 colors, and then go back and selectively re-optimize the slices that need to look better, locking in the border colors as you go so they'll match the adjacent slices.
posted by bricoleur at 9:26 AM on June 13, 2005

I always flatten PSD files first and generate my images from them - after I've built a template with HTML and CSS and that incorporates all the elements of the layout that can be coded. So, start coding - then slice up the portions of the images that you need maintain as images.
posted by annathea at 10:02 AM on June 13, 2005

Thought of one other thing that could save you some hair-pulling. Set guides in Photoshop at all the logical junction points in the page: edges of discrete images, edges of text areas, edges of solid color, etc. Then jump to ImageReady and set the slice tool to "jump to guides." Otherwise it's a bitch. You can even let ImageReady create slices from the guides, and then go back and tweak by hand, consolidating where practical with the slice tool.
posted by bricoleur at 10:27 AM on June 13, 2005

I write this after making certain assumptions about what you're getting at. Please ignore me if I'm not being helpful here.

The web page will be more than a big image sliced up and delivered in a table, once you've coded it. You will add all of those semantic and accessibility data. Google will know what it's about if the content is clear and the markup is identifiable, whether you used DIVs or tables.

Tips, I guess:

A short statement at the top of the document along the lines of "A web site showcasing the photography of Joey Shabadoo, specializing in foo and bar, as seen in such and such" is in order. Make it the first thing the robot will find when it reads the page. If he literally leaves no room for text in his design, z-index the text under an image or something, so that the spider still sees it. Link to other, similar sites, with descriptive link labels. Title and Alt all of the images properly. Don't worry about meta keywords, since Google ignores them. In general, label everything properly and you should be golden.

It's not up to him to think about all that stuff -- he's an artist, not a designer, and certainly not a programmer. Think of it as your challenge to make sure the indexers have all the information they need to get him "mad hitz".

Tangent: the whole "don't use tables for structuring" argument is faulty, as I see it, for this list of (well-worn) reasons:

• People are the primary audience, machines secondary.
• CSS doesn't provide a feasible alternative to tables as far as structuring pages the way humans want to read them.
• People who use DIVs for structure don't necessarily use them in a semantically meaningful way, so there's no guarantee that switching away from tables gives you any benefit. Considering this, the amount of useful information CSS structuring provides is probably less than it would seem at first, and a cost/benefit analysis for each site is in order.
• A search engine that can't tell when a table cell is being used in place of a DIV is stupid anyway.

posted by Hildago at 2:55 PM on June 13, 2005

...the whole "don't use tables for structuring" argument is faulty

I wouldn't disagree with any of your reasons, Hildago, but there are good reasons for steering clear of tables in some cases. First and foremost with my clientele is that pages built on DIVs, when properly arranged and commented, are much easier for a client who knows little HTML to update himself/herself. Complicated nested tables can get really nasty when you drop in a new, larger image, or add one character too many to a text field.

I used to rely solely on tables, but am moving away from that approach. I'm finding the finer points of CSS positioning and, especially, the various browser idiosyncracies with respect to margins and padding, pretty hard to grok, but the more I get it, the more I like it. Substantial revisions to complex table-based pages often require a complete rebuild from the PSD. CSS-based pages, on the other hand, can be radically and quickly reworked by building a few new images and tweaking x, y, and z indices.
posted by bricoleur at 5:06 PM on June 13, 2005