Blog RSS feed
4 posts
in February - 2005
The Melodius Sound of Tuning your sIFR
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).
- I found that using Firefox with Chris Pedrick's Web Developer's toolbar while tuning was very handy for turning JavaScript off and on for comparison -- without reuploading the page. So for the rest of these tips, I've used Firefox with Chris' toolbar. After any of the below tweaks, I simply uploaded, viewed with sIFR, turned off the JavaScript, refreshed the page, and viewed the decoy.
- 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.
- In the bottom of your page, in the actual JavaScript replacement statements, the order they're entered can matter. I had a page with an h4 styled as a callout, with borders and padding and margins. I found that Internet Explorer Mac was shifting the next heading, an h3, to the right about 30px. (Internet Explorer Mac also put the bottom border directly beneath the top border, as if nothing was in between. I simply hid the border from IE Mac. But the shifting was still happening.) I noticed as the page loaded that the h3 seemed to be loading first and then getting shifted by the h4 above it when it loaded. Changing their order in the replacements so that the h4 was before the h3 fixed that little problem.
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. ;)
Category tags: Accessibility, CSS, Designing for the Web, Dreamweaver, Flash
Posted by Stephanie
Add comment |
View comments (3) |
Permalink
|
Trackbacks (0)
|
Digg This
Coming to a Device Near You
Posted Monday, February 14, 2005 9:48:30 AM by Newman
Just read an interesting article on TechWeb about Macromedia's new licensing agreement with Nokia. According to the article, "Nokia would incorporate Flash development tools within the tool sets Nokia provides to the 1.8 million registered developers in its Forum Nokia community, opening up a 'huge' market for Macromedia."
Flash Lite 1.1 is already bundled with Samsung handsets, but this announcement means that Macromedia "now has agreements with two of the top five handset makers."
You can learn more about Flash Lite, and download the Content Development Kit (CDK), in the Mobile and Devices Developer Center. Developers can also purchase Flash Lite Player from Macromedia for US $10. Here is a list of currently supported devices.
I'm looking forward to the day when Flash is installed on digital VCRs such as TiVo. The latest announcement about IPTV, and its interactive features, is an important first step. Let's just hope we don't have to purchase Norton AntiVirus for Microsoft TV...
Category tags: Flash
Posted by Newman
Add comment |
View comments (0) |
Permalink
|
Trackbacks (0)
|
Digg This
Storing Arrays in Shared Objects
Posted Friday, February 11, 2005 4:34:36 PM by Newman
Here's a weird one. I recently completed a Flash application in which two combo boxes and a list share the same data provider. Everything worked fine until I stored the array in a shared object. Then the List component began to display multiple selections, even though the multipleSelection property was set to false.
Several hours later, I looped through the contents of the shared object. Turns out, it was storing the DataProvider.__ID__ property. And what's more it was storing duplicate values. Hence the multiple selections. The workaround was to loop through the shared object and delete every __ID__ property. Of course, this largely defeats the purpose of using the DataProvider API.
var len:Number = myCookie.aEngines.length;
for(var i:Number=0;i<len;i++){
if(myCookie.aEngines[i].__ID__ != undefined){
// remove DataProvider.__ID__ property
delete myCookie.aEngines[i].__ID__;
}
}
This is one of the things that drives me nuts about the v2 components. One shouldn't have to spend half a day debugging issues like this. If the DataProvider class had been more carefully written, all of this could have been avoided. For example, this is the code that generates the __ID__ property, which is "used in data-aware components to keep lists of what items are selected" (see LiveDocs):
//::: Adds a "lazy" Unique ID facility to all objects.
Object.prototype.LargestID = 0;
Object.prototype.getID = function()
{
if (this.__ID__==undefined) {
this.__ID__ = Object.prototype.LargestID++;
_global.ASSetPropFlags(this, "__ID__",1);
}
return this.__ID__;
}
_global.ASSetPropFlags(Object.prototype, "LargestID",1);
_global.ASSetPropFlags(Object.prototype, "getID",1);
Why isn't __ID__ a private property, and why doesn't the DataProvider class generate a truly unique ID?
If Flash is going to be adopted as a reliable platform for deploying Rich Internet Applications, the components have to work all of the time - not just most of the time. That's why there's already great anticipation about Grant Skinner's GLIC components: developers are clamoring for reliable Flash components.
So here's my wish list for the next iteration of the Flash components. They must be:
- Reliable
- Lightweight
- Easily skinned
- Easily styled
- Easily extended
- Less CPU-intensive
While we're at it, creating your own components is not exactly a walk in the park either. Looking forward to 8-Ball... ;-)
Category tags: Flash
Posted by Newman
Add comment |
View comments (0) |
Permalink
|
Trackbacks (0)
|
Digg This
Automating the creation of sIFR font SWFs
Posted Wednesday, February 02, 2005 12:20:37 PM by Sheri German
How many years have I been telling students that they need to be careful about the fonts they put on their web pages? That they need to provide common fonts that are likely to reside on most user systems? That they need to list several fonts so that if the user's system doesn't have the first in the list, perhaps the second or third font is there?
So much for that little piece of sage advice. Enter sIFR (scalable Inman Flash Replacement), which may very well revolutionize font choices for the Web. With sIFR and JavaScript you can specify certain selectors on your page that you want to replace with a Flash file that displays the replaced text in the font of your choice. If you're not familiar with the sIFR technique, you can read all about it here.
Today CMX's Danilo Celic has released a free tutorial that will explain how you can automate production of multiple sIFR font SWF files by using JSFL (Flash JavaScript) within Flash MX 2004. Using the create_sIFR.jsfl script provided with this tutorial, you can create scores of sIFR font SWFs in well under a minute.
So if you want to save time and effort, read on to learn how, through the magic of JSFL and a little variable editing, Flash MX 2004 can be used for automating the creation of sIFR font SWFs.
Category tags: Dreamweaver, Flash
Posted by Sheri German
Add comment |
View comments (9) |
Permalink
|
Trackbacks (0)
|
Digg This
4 posts
in February - 2005