Agile Development is in danger of slipping into the ditch already occupied by brainstorming sessions, train-the-trainer, and team-building: that of management double-speak and great ideas used as excuses to continue the same old practices.

I know I’m not the first person to point all this out – however, unlike many of them, I don’t see Agile as a panacea or a ploy.  It is precisely because I believe in the principles of Agile Development that I feel a little twinge of pain when I see it going wrong.  Rather than trying to forecast why it must fail or trumpet its invincibility, this post is simply trying to paint some yellow stripes on the bumps in the road, in the inevitable web list format:

1) Working From Small To Large – Agile Development aims to put practical decision-making in the hands of the people doing the work.  This sounds dangerous to the people who ostensibly have the “vision”, as they realize that real-world concerns are shaping “their” project.  However, this is only a problem when there are errors in the vision in the first place.  As Getting Real aptly points out, this style can only work when a motivated team understands and embraces the vision of the project.  If management thinks, “well, I’ve got a superb and agile team of developers over here and a great concept over here – now all I have to do is start assigning tasks”, the project is doomed to snarl.  After all, agile development teams don’t need reams of documentation and planning, right?  Sometimes that’s true, and then only if they deeply understand the goals of the project.  Agile Development is like high-end audio gear.  It can make everything shine, but it will also highlight all the flaws.  Make the effort to get your direction aligned before you start your project running.  You want a nimble bobsled team, not a game of tag.

2) Agile Development on a Non-Agile Project – How many workstations have felt the concussion of a developer’s forehead after the project manager (or the project manager’s manager) stops by to report that the glorious, elegant solution the developer came up with is nixed for a reason that the developer herself had pointed out weeks, maybe months ago.  Agile teams are supposed to respond to change quickly and enthusiastically.  However, agile precepts are corrupting when applied to non-agile projects.  If the business isn’t sure what they want, it means trouble for most projects, but an immediate fail for an agile project, which is better adapted to change, but also more vulnerable to it.  Even cases where the business side is focused may not be suitable for agile methods.  For example, one of the main tenets of Agile Development is that developers and business units collaborate to find the best approach for the customer.  If you are Apple, you make your living by exceeding the curve and leading your customers (in theory) to the right place.  However, if you are in an industry that requires stable, trusted solutions (banking would be one that comes to mind), you would do well to temper that agile enthusiasm with a solid dose of risk assessment.

3) Teams Not Independent – Unlike the previous examples, this one is a prime example of giving lip service to an idea while ignoring it completely in the day-to-day life of a project.  Micromanagement and agile do not go well together.  Though this is a well-known problem in many types of projects, it actually goes against everything agile stands for.  The Agile Manifesto points out that face-to-face discussions are the most effective means of conveying information.  But what do you do when you’re having a face-to-face conversation with someone who wants to insert personal preferences into his developers’ work?  Or when management cannot protect the team from peripheral, time-sapping requests?  In these cases, it may be best to put your nose to the grindstone and polish up your resume.

4) Over-Employment – So far, we’ve touched on common problems, but this point is rooted directly in the areas where agile excels.  The concepts of Agile Development have proven so successful that many developers expect to find them on day one: being able to call on business personnel to clarify / collaborate over requirements and solutions; the use of small teams to accomplish discrete tasks; flexibility in planning; experimentation and prototyping as integral to the development process.  When you’ve got it, you don’t need to push it.  You don’t want to show off the strings you just cut and find yourself holding the strings in the process.  If your developers are in the comfort zone, don’t push them out of it just to try and fulfill what someone says is “properly” agile.

5) Scope Defenses Are Down – We’ve all heard that change is key to success, and in the world of software development, the ability to rapidly change direction can mean a decisive edge on the competition.  But there is a big difference between an agile redirection of resources and a stumbling, careening project that no longer knows where it’s going.  Part of this involves scope.  Imagine a current of water traveling through a gulley.  You realize you need to divert the gulley 90 degrees to the left.  What happens if you dig out a leftward channel but also leave the gulley intact?  Imagine doing this every time the project needs a change – you are left with a flooded delta, not an effective change.  If developers or managers are thinking “this is an agile project, so scope creep shouldn’t matter”, they are lining themselves up for a waste of resources and a messy, unfocused project – there is nothing agile about that.

6) Weak Push-Back – If Getting Real gets unrealistic at points, it’s probably in the area of push-back on feature requests.  Sure, if you’re a crack team of multitalented developers and designers with a shared vision and a successful product, you can afford to ride out an initial wave of resistance as customers adjust to your latest release.  When you have a corporate customer relations manager whose phone banks are blowing up, and he’s coming over to speak with your boss, things “get real” in a hurry.  For Agile Development to fulfill its promise of responsiveness, developers must – somewhat ironically – be allowed to provide context to the business.  As usual, communication early and often is key.  Remember that good developers want their applications to be effective and well-received.  Imagine that your team and the business are on the same page, you think you have a brilliant answer, you roll it out, and the users hate it – and continue hating it.  Agile Development can really shine for you here.  Now imagine the same situation, except that the developers knew users would hate it, and they said so, but you didn’t listen?  How is the fix going to go?

7) Paying The Bills – An agile team should, according to The Agile Manifesto, be able to run indefinitely, making changes and adjustments, keeping up a regular pace.  This does not mean, however, that kludges and workarounds should be allowed to fester when they can be cleaned up.  Get Real puts it well: “The same way you should regularly put aside some of your income for taxes, regularly put aside some time to pay off your code and design debt. If you don’t, you’ll just be paying interest (fixing hacks) instead of paying down the principal (and moving forward).”  If your team is maintaining a constant pace, they’ll be fixing these issues eventually.  Better to account for it.

8) How Do We Do This – Agile Development requires not just developer feedback on the project itself, but developer feedback on the process.  The Agile Manifesto calls this “tuning”, and requires it at regular (and, we can assume, scheduled) intervals.  Failure to pay heed to this tenet of the manifesto results in what I like to call “Casual Development”, with everyone plugging along, ignoring opportunities to create efficiency and save time and money.  Can there be a better rationale to the business side than “this will save you time and money”?  A regular reflective breather helps create more smoothly running teams and exposes issues that may be silently eating away at a project.  It also gives deeper meaning to the term “agile” itself: the ability for a team to self-diagnose and fix issues before they arise.

9) Docu-drama – As someone who enjoys writing, making diagrams, and having sensible project outlines, I’ve never had a problem with documentation, unless it’s bad documentation.  Some developers and managers act like documentation is a pure waste of time, or else as archaic as stone tablets.  This is hubris.  Thinking that having an agile project means documentation is superfluous is to ignore the experience and wisdom of others – is your project so cutting edge that no one has ever attempted anything like it before?  Then maybe you don’t need documentation, and you can just wing it on the strength of your genius.  Will no one ever touch your application besides you and your team?  Surely if they do, they will simply read through your sublimely intuitive and graciously commented code and instantly intuit exactly what is going on.  Just like pre-writing is a great creative exercise for all kinds of non-linguistic projects, documentation is immensely helpful to produce, even if you think you’ll never need it.  Go ahead, get your thoughts, your vision, your risks and assumptions, you technical specs down on paper.  You may be very glad you did.

10) Users?  What users? – Oh, the poor, poor users.  Who is looking out for them in the world of Agile Development?  One of the main creeds of Agile Development is that everyone should be looking out for the souls who have to use our wonderful applications.  Too often, no one is looking out for the user, so caught up are they in the idea that in the modern, agile era of development, all the user has to do is wait until the next release.  The truth is that sometimes the business and the development teams get together and end up with zero idea of how users are going to react.  Here we come full-circle: some projects are well cut out for Agile Development, and some are not.  If you are a small startup and you’re desperately trying to get your app to market, agile may be what you’re looking for.  If you’re in the midst of transitioning a legacy application that thousands of users are relying on daily, you may want to (shudder) think of your users first and your developers second.  As I’ve pointed out, many agile habits have already worked their way into the mainstream, so don’t be afraid to be a bit selective about how far you want to push the methodology on any given project.  At 37 Signals, users can marvel at the process, but that doesn’t mean your users necessarily want to be made aware of your process.  It pays to spend the time and effort to get to know your users.

Agile Development is neither a gift from above nor a mere trend – it’s an important crystallization of ideas that can often provide real clarity of purpose for developers and help projects adjust to a fast-changing world.  But it can also be a destructive force if used carelessly.  It’s like business casual: it can be fun and freeing, but in some circumstances and some hands, it can be disastrous.  I hope this post helps you choose your outfit wisely.

With the iPod and iPhone, Apple looked like world-beaters, and when the app store opened, developers flocked to pay Apple $100 for the privilege of downloading the app SDK; they began furiously pumping out apps and biting their fingernails while Apple’s team personally verified the worthiness of each app.  Okay, we get it: part of the iPhone experience is knowing that every app has been tested and approved; it’s quality control.

It seems that much of the debate right now is whether Flash is an open standard and/or whether apps written in objective C are open and/or which company is behaving like the biggest crybaby.  Really, neither is an open standard.  If you want to develop an iPhone app on a Windows machine or if you’re looking to compile some Actionscript without running Flash, you have to use third-party software in either case.  These companies are like two toddlers whining at one another for not wanting to share their toys.

Jobs does have some points – Flash is not the best for use in iPhone apps, and not just because adopting it for the app store would punish all of Apple’s loyal developer community, who plunked down dollars for the SDK.  Having developed in Flash, I’m willing to believe Apple’s claims about Flash’s memory issues (remember ye olde garbage collection issues?).  However, WebKit is the best mobile browser anyone has ever seen, and it doesn’t support Flash.  On this point, there seems to be no good rationale.

Let Apple keep Flash out of the app store.  That’s their bread and butter – okay.  But creating a mobile web browser that doesn’t support the plugin that’s installed on over 95% of desktop browsers – including safari – is just bitterness manifested.  Other mobile browsers support Flash, and yet Apple seems too content to let the market pass them by in this regard.

The worst part is that Jobs and his supporters are offering HTML5 as a panacea.  Sure, it’ll be great – whenever it’s fully supported – but its video component will lack much that Flash is able to do fairly easily now (real interactivity, for example), and its codec of choice, H.264, is proprietary.  Having most players agree on a proprietary format is not the same thing as an open standard.  Oh, and it leaves out Firefox, which is, by the way, open.   It’s like telling commuters that everything will be great when we get our hovercars that run on solar power.  In the meantime, your car is not welcome on our road.  Jobs and his backers may have a point that Adobe treated Apple like a second-class citizen back in the 90s.  Which they were.  Now, I love my Apple products like anyone else drinking the multimedia development koolaid, but wasn’t Adobe doing the same thing to Apple back then that Apple is trying to do to Adobe now?  If the open revolution proved anything, it’s that having a zen-like indifference to such petty squabbles produces winners.  Did Zend worry about Microsoft?

Jobs’ blog post hints at the decades of recrimination by recalling the early days when Adobe and Apple were both based in similar garages.  Get over it.  It’s Final Cut Pro and Aftereffects.  No one will ever use the combination of Premiere and Motion.  Flash is better for the web.  Mac apps are better for Apple devices.

It seems that offering Flash support in Apple’s mobile WebKit browser while keeping Adobe out of the app store market would make everyone relatively happy, but unfortunately, it seems such realism is lacking in the relatively closed and high-ego world of large-scale software development.

update: proof Flash can hang on Apple mobile devices after all?

But for now, the rel tag is easy, supported, and makes getting a little bit of meta information to your script quite easy.

Two uses I’ve written recently are:

(1) Creating abstracted div collapse scripts.  The script just looks at the rel tag for the link and finds the matching rel tag among a class of divs on the page.  Anything matching is shown, anything not matching is hidden.  I never have to go back and touch the script, and I only have to add a rel tag to my divs.

(2) Letting my css-based navigation know which page we’re currently on.  With includes, the idea that your navigation should reflect your current page location fell out of favor a bit.  Kind of suspicious, if you ask me.  It often seems designers and front-end developers adapt their pet styles to suit the latest technology.  Regardless, it’s dang easy with the rel tag to revert to the “old” style of location-aware navigation.  I just drop a rel tag in my nav links and a matching rel tag in my content div within the content include file.  They search for each other.  They find one another.  It’s like an interface component romance paperback.

Part of the reason that HTML 5 is going to include some developer-defined tags is that people have been using rel and a few other tags to include meta data (and sometimes some not-so-meta data) in their front-end code.  I completely understand the cold chill that comes over some folks when they start contemplating gobs of data gooping up the front end.  I also think it’s possible to fret too much.  As the linked article above points out well, it’s possible to include some meta data inline and still be semantically useful, degrade nicely, and not offend the browser.

If people hadn’t been expanding on the uses of the rel attribute so effectively, we may not have had the push for user-defined attributes in HTML 5.  This is a good thing.  It’s important to remember this truism: no amount of standards will stop people from writing ugly code.  But, paying attention to what developers are doing in practice and honoring those practices in new standards definitions can benefit everyone.

Hangin at the Bottom

We’re just psyched to be in a google result page with the likes of James O’Reilly and actionscript.org.

Hooray!  If you haven’t checked out the code yet, by all means please do.

It looks like CSS3 will have some pretty cool new attributes available for us developers.  Of course, it’s all proposed and not released yet, but let’s start salivating anyway:

One really cool thing with the potential for hilarious abuse of power is a proposed scale attribute.  Use your own imagination on that one.

But that’s not the best.  The best (if truly implemented) would be a set of CSS specs for creating a multicolumn layout without having to resort to javascript trickery, fakey background images, or ridiculous amounts of div nesting.  Great news, everyone!

Found on these sixrevisions posts.

Dagnabit!  What is the point of combining xml and html standards if I can’t use them together all the time?  I know, you may be thinking, but xml is not html , no matter what you throw into your nodes.  You’re right, and this is exactly what jQuery tells us.  You can grab the text contents of any node, but if you have html tags in there, the .text() method in jQuery will just look right past them.  As it should.  This works fine, for little snippets like my titles, but what if I want to put some (ostensibly) well-formatted html code in my data?  Further, what about all those applications where you want to store html snips in a database and read them out in XML?  How do you get around this?

For that, we’d want to use the .html() method of jQuery, and for that, my friends, we suddenly get quite strict.  XML, according to jQuery, is not html, and so has no innerHTML quality for the .html() method to grab.  It doesn’t matter, says jQuery, if your html code is so well formatted that it can be parsed as xml…it’s just not possible to access an html-specific property that does not exist.

Like fun, I say!

But before we get to the solution, let’s heartlessly go over some available options:

1) We could punt on the whole jQuery thing and use Flash, which knows just what to do with a string of html parsed from within an xml node.  Furthermore, Flash has a nifty .htmlText property on its text fields, and although the formatting of said html pales compared to real css, it will faithfully render as html anything you tell it to, caveat codeur.  Since the project in question did involve some Flash, this was an option, but one of the points of the project was to take the same xml data and have both flash and jQuery parse it for different purposes, and thereby provide ease for content providers and improve accessibility.  So doing the whole thing in Flash was out.

2) We could escape the heck out of all our characters and turn the whole node into a mess of html character codes.  Un-fun to code and messy for the content people.  Also, I tried that and it rendered out a block of actual html onto my screen.  I’m sure I could have reconverted those characters back into actual html behind the scenes, but again, un-fun and a hassle.

3) Use a fancy xml consuming plugin or script.  There are some neat ones out there, and I tried one in particular that looked pretty good, but it seems they have a common issue – you have to know what tags you’re looking for in order to seek and replace within the script.  Some of them will hunt for anything that looks like an html tag in the string and convert that, but mostly these plugins seem like scripts that people wrote to perform functions for themselves, and then extracted and shared.  Which I applaud.  But these were not what I was looking for, and I found the implementation sometimes troublesome.

4) [Warning: bad solution] Hand jQuery a bag of grapes and say it’s “nature’s jellybeans” (at least that’s what my mom used to do to us).  It goes like so: grab your xml file with an ajax() call, and use the optional key/value pair:

dataType: “html”

And then you’d do ike so:

$.ajax({ url: “myXMLdoc.xml”,
dataType: “html”,
success: function(xml){
var myHtmlContent = $(‘node’,xml).eq(id).find(“nodeName”).html();
$(“#targetdiv”).html(myHtmlContent);
}
});

…and there you have it!  Or, would…if…

…can you see where this is going?

…search your feelings, Luke…

…if only Internet Explorer handled the XMLHTTPRequest result like the rest of the world!  Like most Microsoft stuff, IE, with its own version of the XMLHTTPRequest (someone correct me if I’m wrong on that), wants to get too clever and won’t let you, the developer, tell it what kind of data you’d like to see (even if it’s either of several types that are verging toward common standard).  No siree!

Supposedly, recent versions of IE (7+) have their own XMLHTTPRequest, not the previous Microsoft HTTPRequest.  However, the Microsoft XMLHTTPRequest doesn’t behave like the other girls and boys, even in the recent versions of IE.  Now, this post didn’t start off to be a discussion of the supposed evils of Microsoft’s proprietary habits.  But who else has almost 11 million results on a google search of how much they suck?  Hint: not Chrome (3 M), Firefox (1 M), or Safari (1 M).  (Can’t evaluate Opera on this critrion because sadly a lot of people out there think that real, actual opera – the music – sucks too).  For comparison: “yanni sucks” (400 K), “death metal sucks” (700 K), “paris hilton sucks” (1 M), “the lions suck” (1 M), “tv sucks” (11 M), and “new york sucks” (12 M).  So, yeah.

Anyway, after that turgid digression, finally, we come to the solution.  And…

It’s simple!  Maybe I’m, like, the last one to figure this out, but you just use XML’s CDATA declaration, and wrap it around our html code within our xml node.  If I had found that idea earlier, it would have saved me some time, but I would have missed a brain-scratching moment or ten for sure.

Anyway, this is fascinating to me for several reasons:

a) When oh when is Microsoft going to just give up and give us a truly standards-compliant web browser?  Maybe they should spin off a company whose software is intuitive and flexible and plays nice with others.  Oh wait, they already did that.

b) With the XHTML standard in full force, it seems totally silly that one would have to pass off perfectly valid XHTML within an xml document as CDATA.  Isn’t the whole point of XHTML to be able to one day have a semantic web, where code itself can be meaningful?  How far away are we when it’s trouble to get even well-formatted html out of my xml nodes without basically commenting it out?  In theory, that means I can’t parse through my html elements, which seems to go against the whole ethos of XHMTL.

Well, heck.  I remember when CSS was going to put an end to bad code.

Objects can be “floated” in a variety of ways, and with a great deal of flexibility: you can assign pads to your objects within the context of their float, and even use simple math to create custom interactive behaviors for your objects.  The package is extremely lightweight and flexible.

jsFloater also computes the centering math on your own objects for you.  Standard movieclip 0,0 top left registration is expected.

For an example, see the jsFloater example swf, which contains an object for each available float method in the jsFloater class.  Mousing over these objects reveals their method, their float mode, and their current pixel x – y coordinates.  The example swf acts as a kind of visual API guide.

The class is located in the package, com > seagull > jsfloat.   Move the directory “seagull” into your “com” directory, and add the following line of code either in your appropriate package declaration(s) or, if you are using Actionscript 3 within your own FLA file, at the top of your script:

import com.seagull.jsfloat.*;

Before you start floating your elements, several other things must happen:

1. Put a listener on your stage, listening for the Event. RESIZE event.  More on this here.  Basically, this could look like so:

stage.addEventListener(Event.RESIZE, floatStuff);

This will call a function you create – in this example, it’s named “floatStuff”.

2. Align your stage to the top left and instruct it not to scale content.  The code is below:

stage.scaleMode = StageScaleMode.NO_SCALE;
stage.align = StageAlign.TOP_LEFT;

Be careful with your publish / export settings using these stage properties – make sure they do not conflict.

3. Instantiate the jsFloat class.  To do this, simply create a new object of type jsFloat, and pass in your intended minimum stage height and minimum stage width.  In this example, we have created a design that requires a minimum stage size of 960 x 600.  Smaller than this, and our elements will start to crash together, so we instantiate the jsFloat class with our values:

var floater:jsFloat = new jsFloat(960,600);

You could also create variables to hold your minimum stage dimensions and pass those in as well, or even write code to destroy the floater object and re-instantiate it with a new minimum size, depending on some user interaction, etc.

Okay, now we’re ready to begin floating our elements.  For this example, we’ll use three made-up, generic variables called “sprite1″, “sprite2″, and “sprite3″ that we want to float.  Now, we need to construct the function that will handle our resize event.

function floatStuff(re:Event):void
{
var sW:Number = stage.stageWidth;
var sH:Number = stage.stageHeight;
floater.floatHorVer(sprite1,”center”,0,0,sW,sH);
floater.floatHor(sprite2,”rightStrict”,20,20,sW,sH);
floater.floatVer(sprite3,”bottomStrict”,100,10,sW,sH);
}

Note: if you are copying the code above, you will have to re-do the double quotes so that Flash recognizes them.

So, what’s going on there?  Let’s take it line by line.  The first line sets up our function (you could make this private, if you like) with the same name as that called by our earlier event listener.  Since it’s called by an event handler, it wants to receive an argument that represents the event, so in the parentheses, we create an event called “re” of type “Event”.  This function is not returning anything, hence, the “:void”.

The next line opens the function with the curly brackets.  In the two lines following that, I have created two variables of type “Number”, which will hold the current stage width and height values.  It’s important that these go inside the resize event handler, so that they will be re-computed every time the user resizes the browser window / stage.

Next, I call the “floatHorVer” method on my floater object, passing in our sprite1 object and using an align mode of “center” (aligning “sprite1″ to the center of the stage), and I’ve given it an xPad and a yPad of 0, which means it will sit right in the middle.  Finally, I pass in the current stage width and stage height, contained in my sW and sH variables.

In the line following, I call the “floatHor” method on my floater object, and I pass in my second sprite.  I want this sprite to always be 20 pixels down from the top of the window and stay 20 px away from the right edge of the window, so I use the “rightStrict” mode, and I pass in a yStick of 20 (sticks the y value at 20) and an xPad of 20 (pads the resized x value by 20 from the edge).  Then I pass in the current stage width and height.

Finally, I call the “floatVer” method on my floater object, passing in my third sprite.  For this sprite, I want an alignment that will always be 100 pixels off of the leftmost window edge, and I want it to always be 10 pixels above the bottom of the window.  I pass in the “bottomStrict” mode, and an xStick of 100 (sticks the x value at 100), then a yPad of 10 (pads the y resized y value by 10 from the bottom).  Then I pass in the current stage width and height.

If you’re wondering why the floater object keeps getting re-used, think of it as a invisible gnome that is called into action when the window resizes – your calls to it represent a list of tasks for it to complete – so, even though we’re floating 3 different sprites, we’re calling the same floater object to accomplish all those tasks.  Also, the floater object will generate an x and a y value for whatever object you pass into it.  Thus, do not attempt to use floatHor and floatVer on the same object, as the second one will over-write the first.  Use floatHorVer instead.

To close our function, we use the closing curly bracket.

Okay, we’re almost there!  We only need one more thing to get this running.  We want to call the resize handler (our floatStuff function) once when the script runs, because otherwise we’ll have to wait for the user to resize the window for any of this to take effect (and we don’t want to do that).

The only difference is that this time, the function is not being called by an event handler, so there’s no event to pass in.  Since we’re not actually using that required event argument within the function, we’ll just pass in nothing instead.  So, we have:

floatStuff(null);

That’s the basics!  For more on the various methods and alignment modes available to you using jsFloater, see the jsFloater API, the jsFloater visual API guide / example, and the jsFloater box model.

Because web browsers are anchored to the top left of the window, you may want to use a combination of these three methods to achieve your desired results.  jsFloater allows you to define a minimum stage size, so that your elements won’t crash together if the user squashes the page size down by dragging the browser window’s bottom right corner to the middle of the screen, for example.  This minimum stage size is passed to the class constructor on instantiation.

There is a visual guide to the API available both in the downloadable zip file and also for browsing on this site.  You can mouse over the various objects in the visual API guide to reveal what method has been used to float them, which align mode they are employing, and what their current pixel x – y coordinates are.

jsFloater allows you several types of floating, in addition to the ability to “pad” or “stick” your floats, as will be expained below.  The types of floating are proportional (based off of the difference between the minimum stage size and current stage size) or Strict, meaning based only on the current stage size.

The methods:

constructor

public function jsFloat(sIW:uint, sIH:uint):void

returns: nothing

parameters:

sIW:uint – stage Initial Width.  This is also the stage minimum width you define based on your designs.
sIH:uint – stage Initial Height.  This is also the stage miniumum height you define based on your designs.

Both of these parameters will be used to calculate values in the proportional float modes and will also set the values for browser window resizes that are smaller than your minimum.

floatHor

public function floatHor(obj:Object, align:String,  yStick:int, xPad:int, sW:Number, sH:Number):void

returns: nothing.

parameters:

obj:Object – the object passed to the method.  Can be sprite or movieclip as well.
align:String – the alignment mode.  Options are:
“left” – aligns left, proportionate to minimum stage size
“leftStrict” – aligns left, based strictly on current window size
“right” – aligns right, proportionate to minimum stage size
“rightStrict” – aligns right, based strictly on current window size
“center” – aligns center (horizontally) in the window
yStick:int – allows you to force the floated object to “stick” to a particular y value.  A horizontal float with a yStick of 0 will align vertically with the top of the browser window.  Negative values can be used, as well as your own math (provided it results in an integer).
xPad:int – allows you to pad your float values.  For example, if you are using an image that always needs to be 20 pixels from the right edge of the window, you would use the “rightStrict” mode and and xPad of 20.  Positive values for pads will move objects toward the center of the window (horiztontally, in this case), except when using the “center” mode, which moves positive values toward the right.  Negative values can be used, as well as your own math (provided it results in an integer).
sW:Number – current stage width.
sH:Number – current stage height.

floatVer

public function floatVer(obj:Object, align:String, xStick:int, yPad:int, sW:Number, sH:Number):void

returns: nothing.

parameters:

obj:Object – the object passed to the method.  Can be sprite or movieclip as well.
align:String – the alignment mode.  Options are:
“top” – aligns top, proportionate to minimum stage size
“topStrict” – aligns top, based strictly on current window size
“bottom” – aligns bottom, proportionate to minimum stage size
“bottomStrict” – aligns bottom, based strictly on current window size
“middle” – aligns middle (vertically) in the window
xStick:int – allows you to force the floated object to “stick” to a particular x value.  A vertical float with a xStick of 0 will align with the left side of the browser window.  Negative values can be used, as well as your own math (provided it results in an integer).
yPad:int – allows you to pad your float values.  For example, if you are using an image that always needs to be 20 pixels from the bottom of the window, you would use the “bottomStrict” mode and and yPad of 20.  Positive values for pads will move objects toward the middle of the window (vertically, in this case), except when using the “middle” mode, which moves positive values to the bottom.  Negative values can be used, as well as your own math (provided it results in an integer).
sW:Number – current stage width.
sH:Number – current stage height.

floatHorVer

public function floatHorVer(obj:Object, stickMode:String, xPad:int, yPad:int, sW:Number, sH:Number):void

returns: nothing.

parameters:

obj:Object – the object passed to the method.  Can be sprite or movieclip as well.
stickMode:String – analogous to the align parameter in the methods above.  Options are:
“center” – aligns to the center (horizontally) and middle (vertically) of the window
“right” – aligns vertically to the middle and horizontally to the right, proportionate to the minimum stage size
“rightStrict” – aligns vertically to the middle and horizontally to the right, based strictly on current window size
“bottom” – aligns horizontally to the center and vertically to the bottom, proportionate to the minimum stage size
“bottomStrict” – aligns horizontally to the center and vertically to the bottom, based strictly on current window size
“bottomright” – aligns to the bottom right, both proportionate to the minimum stage size
“bottomrightStrict” – aligns to the bottom right, both based strictly on current window size
“bottomleft” – aligns to the bottom left, proportionate to the minimum stage size
“left” – aligns vertically to the middle and horizontally to the left, proportionate to the minimum stage size
“topleft” – aligns to the top left, proportionate to the minimum stage size
“top” – aligns horizontally to the center and vertically to the top, proportionate to the minimum stage size
“topright” – aligns to the top right, proportionate to the minimum stage size
Note: because the browser window is anchored to the top left, certain stickMode parameters for this method would be redundant.  For example, there is no topleftStrict, as that effect can be achieved with the floatHor method, taking an align mode of “leftStrict”.
xPad:int – allows you to pad your float values horizontally.
yPad:int – allows you to pad your float values vertically.
xPad and yPad are as described for the methods above.  Either can accept negative values and math that results in an integer, except that both will push objects toward the center (horiztonally) and middle (vertically) of the window when given positive values, unless the “center” mode is used, which will push positive values down and to the right.  For example, if you wanted two objects to float at the center of the screen, with one always offset from the other 20 pixels down and to the right, you would float the first using the floatHorVer method with xPad and yPad of 0 and 0, and float the second using the same method, with an xPad of 20 and a yPad of 20.
sW:Number – current stage width.
sH:Number – current stage height.

For more, see How To Use jsFloater.

jsFloater requires you to define a minimum and width and height for your stage, so that you can take a given design comp and figure out how small the browser window can get before the objects begin crashing into each other and/or overlapping in undersirable ways.  This is an issue common to liquid GUIs / layouts, one which jsFloater lets you fix.  But, you may not always want your elements to float based upon the very edges of the current browser window: if, for example, your design comp figures at a minimum window size of 800 x 600, you may want your elements to float somewhere between the minimum value and the edge of the window.  You could accomplish that with typical liquid GUI layout types and a bunch of your own math – or, you could let jsFloater do it for you, using the proportional float modes available.

We’ll examine the basic boxes in a moment, but first let’s recap the horizontal and vertical floats.  The images below are all taken from the jsFloater visual API example, which can also be exported from the FLA file included in the download.  It may help you to have the visual API guide open while you read through this example, so you can experiment and see how the objects move and react.

First, let’s look at the available align modes for the floatVer (vertical) method.

jsFloater Vertical align modes

As you can see, one of the objects is floating directly in the middle (vertically), one each is floating at the very top and bottom (strict), and two are floating somewhere that represents the a ratio of difference between the minimum height (height of the dotted box) and the current window height.  Those two are using the proportional modes.

Let’s look at the floats for the floatHor (horizontal) method:

jsFloater Horizontal align modes

Although the left-most horiztonally floating object is currently obscured by the top-most vertically floating object, you should be able to see here how the horizontal mode is analogous to the vertical mode: one object aligned perfectly center, two strictly aligned left and right, and two floating proportionally between the minimum width (width of the dotted box) and current window width.

So, here is what the proportional box looks like, using nine floating modes (including the object at center-middle):

jsFloater proportional box

All of the nine objects being floated in the above box are using the floatHorVer method, width proportional align modes.  This proportional align is based on the difference between the minimum value and the current browser window size, so that elements float out into the browser space proportionally, but to not have to be stuck to the edges of the window, or to a fixed distance from the edges of the window.

Of course, you can combine the different float methods and modes however you like.  One possible use might be using proportional floats of the floatHorVer method for your right- and bottom-most objects, and using other floats for your left- and top-most items, for example.  It’s up to you and your creativity.

Now, let’s look at the strict box:

jsFloater strict box

Notice, in the example above, that we’re now using a combination of the floatVer, floatHor, and floatHorVer methods to achieve a box that goes to the very edges of the current browser window size.  The reason for this can be explained using a simple example: look at the bottom left corner of the box.  That object only needs to float vertically, as the whole browser window is anchored to the top and the left.

Once again, you can assign particular x and y “stick” values to your vertically and horizontally floated objects, respectively.  You can pad the float of any object and also use your own math to create some custom behaviors on browser resize.  Hope you have fun experimenting with the various methods and modes.