Posted Thursday, February 24, 2005 6:08:03 PM by Stephanie
Today was the day to take sIFR over to two client sites. I've played with it and even used it on one where it was only a "here and there" thing. But today, it was a "get ready to deploy sitewide" thing. And so the fine tuning began.
First, if you haven't been introduced to sIFR, get ready for a treat. You're going to be hearing much more about it. I have some earlier posts that link you to all the pertinent info -- Accessible, Beautiful Flash Text, sIFR - The Release Candidate and sIFR Release Candidate 2 Has Arrived. Danilo Celic has a demonstration of sIFR usage and set up in his new Breeze (or is it Captivate?) demo live this week in Macromedia's DevNet center called, Introduction to Scalable Inman Flash Replacement (sIFR). If you have Flash MX 2004, you can automate the creation of an initial group of font swfs using Danilo's tutorial here at Community MX - Automating sIFR Font SWF Creation WIth Flash MX 2004 and JSFL. If you decide to try it out, you'll want to look through Mike and Mark's read me text for basic instructions. The basic explanation of what I'm going to talk about here is -- tuning is the act of making the decoy text (styles affected by selectors such as: .sIFR-hasFlash #h1 ) take up the same amount of space as the Flash replacement text does.
Even though Danilo has made it simple to create the swfs and though sIFR is quite easy to insert into your pages, I found the tuning process to be a bit tricky. I thought I'd share some tips with those that might also want to try it out. Here are the things I found in no particular order:
- First, as recommended, temporarily replace the opening tag of your html element with this: <html class="sIFR-hasFlash">. Then, in your decoy styles, comment out all the "visibility: hidden" declarations. This prepares your page to show you the actual decoy styles (the ones that prepare the space for the sIFR replacement).
- Since in my regular selectors, I write my font values in relative sizes, the first thing I did was put pixel sizes in my decoy styles. This gave me a bit more of a level playing field. That said, increasing and decreasing the pixel size in the decoy style can also change the size of your sIFR replacement text, so keep that in mind. From there, I began the tweaking of the letter-spacing and then the line-height. That's the order that worked best for me.
- If you've used more detailed descendant selectors in your style sheet, you'll want to change your decoy styles from this: .sIFR-hasFlash h2 to something like .sIFR-hasFlash #content h2 (or whatever mirrors your selector). I had an h2 element that occasionally had a class on it (which caused me a great deal of headache before I figured out what was going on). I was able to write a selector like: .sIFR-hasFlash #content h2.separate without a problem, so don't be afraid to get specific where you need to. If you don't do this, the specificity of your regular styles will override the h1, h2, h3, etc of the .sIFR-hasFlash styles if there are similar declarations. For example, if you have line-height in both selectors, and you don't write a decoy style with higher specificity, your regular descendant h* style selector will override the decoy style in specificity value and you won't know why the decoy isn't obeying.
- If you have long headlines, watch where the line break happens in the sIFR and try to match it in the decoy if possible. This is usually done with letter-spacing.
- If you notice a slight "page jumping" as you switch from decoy to sIFR, this likely means that one style is taking up more space vertically. Try adjusting your line-height to make them match.
I still have a few things to work out. I want to play with floating images in sIFR headings -- so far, no go on that. I also had the idea tonight that perhaps putting a font-family in my .sIFR-hasFlash style might start me on a more level playing field each time. At least I'd get used to the sizing of one particular font as well as how it reacts to letter-spacing and and line-height. Today I was working with both Verdana and Trebuchet MS fonts. They definitely react differently. I also have seen a bit of difference in rendering between Firefox, Safari and Internet Explorer. Someone gave me some ideas to try there next time. I, and others, will probably be adding to the sIFR wiki. So come over there and join the fun soon.
Hopefully these tips are coherent enough for you to get a bit of help from them. If not, blame it on the cough medicine. ;)
Posted Monday, February 14, 2005 8:49:29 AM by Stephanie
So you've made the leap and you're now separating form from function. You're using XHTML and CSS and designing to web standards. All your pages validate and you've got the buttons to prove it. Who cares?
Not your prospective client. The quickest way to watch a new client's eyes glaze over is to launch into a diatribe about properly coded pages, usability, navigation and web standards. They really don't care. What they want to know is, "Will my site make money? Will it bring in more customers? How much will it cost me to develop and maintain?"
It's really no different than the way a surfer looks at the websites you create. When they hit the home page, they immediately want to know, "Where am I? What's in it for me? How can you solve my problems? What's the quickest way to the information or product I'm searching for? Can I buy it?" Anything you do to slow them down in meeting these needs is another possibility they'll leave your site and move on to one that makes it easier on them. It's a combination of the avoidance of pain/difficulty and the instant society we live in. Flash intro pages on business sites, just for the site of something cool that moves, leave the user another click farther from their goal.
When discussing a new site with a prospect, instead of trying to educate them about web standards, usability and accessibility, why not simply tell them what's in it for them?
- Smaller page size that decreases their bandwidth, thus saving them money on their monthly hosting charges
- Pages with consistent navigation so that surfers never get lost
- Pages that by nature are easier for search engines to crawl with the ability to put the more important text (full of keywords) toward the top portion of each page
- Pages that don't lock anyone out because of the browser they choose to surf with or their method of surfing (keyboard, screenreader, etc)
- Pages that are very quick to edit, even changing the entire look site-wide, thus saving time and money on site maintenance
You get the picture. The above list is based on the benefits of using web standards and creating a semantically correct, more accessible site. But why confuse them with lingo that only people in the business care about? Show them the benefits, especially the ways they'll save money, and you're that much closer to landing that account for your company.
Posted Monday, February 14, 2005 8:31:31 AM by Sheri German
Forget chocolates! Who needs the calories? Your web pages don't need them either, and you can reduce their weight by using the newest CMX JumpStart: Venice. In the tradition of including unique features in every JumpStart, we've packed this valid XHTML and CSS 2.1 styled, WAI and 508 compliant Dreamweaver template with lots of goodies for a special Valentine's Day treat.
I love the romantic, rounded corners that are featured in both the three-column home page and the two-column form page. I also appreciate how the equal-height for the columns is achieved through faux column technique.
Sure, it's great to have templates as starting points for my clients' sites, but the aspect of JumpStarts that has really been equally valuable to me as a teacher (and forever a student!) is their educational opportunities. There is so much to learn in the eleven included tutorials and extensively commented style sheet.
A new feature in Venice is how its source PNG is organized by new CMX partner Linda Rathgeber, the author of Playing with Fire among other books, according to Fireworks best practices. I've learned to use one file to organize multiple layouts that use shared assets.
When my Valentine's flowers are wilted by the end of the week, or see an early demise at the paws of my nibbling cats, I'll still remember Valentine's Day 2005 every time I use JumpStart Venice.