1. Userzoom (Sunnyvale, CA) provided the technology. They offer UX pros the ability to run online, task-based studies with geographically dispersed participants.
2. KeyLime Interactive (Miami, FL) moderated the sessions. They specialize in online web-based usability testing as well as traditional lab-based testing.

A little background about the study before diving into the results. Each Hotel site tested (Hilton, Marriot, Intercontinental, Starwood, Hyatt) were randomly assigned 50 different users to perform 2 tasks seperatly. Tasks took roughly 10 min in length to complete. Users were selected regardless of their prior affiliation with any hotel rewards program or familiarity with the site.

Tasks:

1. Finding a room on a beach at a particular time of year, particular distance from a landmark, within a set budget of $250.
2. Finding a hotel that provided parking to it’s guests

The web sites were evaluated on several metrics based on the tasks which users attempted to cary out (Overall success, Ease of use, Ease of Navigation, Clear where to start, Satisfaction with Time) and then are given an overall score (KLI score) by the moderating agency (Keylime interactive)

Data gathered from open questioning and Task 1 Results overview:

• Marriot, Hilton had largest groups of rewards program participants – and considered ‘most popular’ by users as well
• Hilton ranks best from a search perspective
• Hyatt ranks worst from a search perspective
• Marriot and Hilton brands scored well on ease of use and accessibility
• Hilton & Marriot score highest on success rate, Ease of Use, and Satisfaction. Hyatt scored lowest
• User satisfaction related directly to the time it takes to complete tasks

Data gathered from open questioning and Task 2 Results overview:

• Marriot scored highest on search, but most users had a hard time figuring out where to start clicking
• Hyatt & Starwood rank consistently low in all categories of evaluation within the task result

The KLI results from the 2 tasks were the aggregated for an overall KLI score

Executive takeaways

• All brands had varying strengths and weaknesses
• All brands have room for improvement
• All brands had a ‘negative’ score of with regards to the brand meeting end-users expectations (Hilton however was the ‘best’)
• No single brand or site should be picked on as being ‘bad’ in strict black and white terms. These results were simply the outcome of 2 tasks performed online. But it starts to paint a picture of the overall User Experience the various brands provide

What I will say is that a little more progressive thinking would help cut out a lot of the senseless number of versions required for some companies running rich media ads and also (potentially) increase your margin for success. So how did I come to this conclusion? Through recent conversation with some ad partners and also jumping through a technical hurdle or two.

We recently completed an XML fed rich media ad for a client. The ad featured a small content management system that allowed the client to update that XML feed and thus create a new ad “on the fly” for as long as they were running their ad unit.

So, why does this matter? It obviously doesn’t seem like a radical concept (or I would hope not ). It’s a process almost all designers have used when building a website. Make something the client can not only use but also maintain. Why? Because it ads value to both the client and the agency.

1.) It cuts down on versioning.
2.) It gives content control to the client.
3.) It removes back and forth (you know, the 45 email chains).
4.) It ads flexibility to their ad campaign.
5.) It ads longevity to the ad.
6.) It softens mistakes.

If you’re asking how? You’re in luck (descriptions below).

1.) It cuts down on versioning - If you’ve ever created a rich media ad, you’ll soon begin to notice that there sometimes are 26 versions of an ad that accomplish the same goal. You’ll probably sit in photoshop or flash at some point and say (or possibly scream) “why am I doing this!?” and with good reason. A dynamic solution allows a designer to create one universal flash ad that updates in real time and then leaves 1 simple static ad (in the event flash cannot be delivered) for each iteration. Instead of doing 26 ads, maybe you can cut it down to 13. In terms of efficiency, that’s obviously huge.

2.) It gives content control to the client - Making the client an active participant helps ads value to what you do. It also ads ownership and accountability to what is ultimately their product. More often than not, that leads to a richer experience all around (which is never a bad thing).

3.) It removes back and forth (you know, the 45 email chains) - I don’t think I’ll explain this one. Why ruin the fun for someone who has yet to experience one of life’s miracles. /sarcasm

4.) It ads flexibility to their ad campaign - So what happens if you’re 5 weeks in to a 10 week ad campaign and you realize what (or the way in which) you’re advertising could be improved. Different wording, a larger percent off, an “hourly discount”, etc. etc. etc. Or what if you sold something that absolutely flew off the shelves and you like to replace another so-so sale, later in the campaign, with that same discount?

How is that going to happen if you have 50 versions of an add that all need updated by a designer, reloaded in to an ad portal and then relaunched individually? The answer is, it’s not.

How about if you have an XML feed that populates those ad units instead? and all their ad sizes (728×90, 300×250, etc., etc., etc.). Update a single text file, hit submit and all your ads just changed in real time. No contacting the agency or the ad portal. Simply update your CMS and hit enter. So why isn’t this design strategy happening more? Maybe it makes too much sense?

5.) It ads longevity to the ad - An ad that updates via an XML document (and not a designer) is not only cheaper over time but it also stands to last infinitely longer than a static ad. Did your campaign change? Are you selling a different product? No problem. Just update the CMS, relaunch the ad and you have now been able to recycle something that typically would have been thrown away. There’s value in that for everyone involved (a superior product, happy customers and ultimately more business).

6.) It softens mistakes - So you spelled a word wrong? (unfortunately been there and done that). What next? Well, it obviously needs changed (my head is starting to hurt thinking about this) and ASAP. In a dynamic ad, 90+% of people are seeing the flash unit. Having the ability to immediately wipe out that mistake for nearly every user in about 60 seconds is HUGE. Log in to the CMS, update the XML and the spelling error is removed. You’ll obviously have to make changes to the single accompanying static ad (if the same error was made) but you’ll SIGNIFICANTLY reduce the pain of a small correction.

So my question is, why are people NOT making more ads that are dynamic, flexible and client friendly?

If you’re shouting “We are! We are!” then I might have just wasted your time……well, while validating your work. I hope you consider that an even trade.

If you’re shouting “Why aren’t we doing this!?” Well…….Why aren’t you? Ads need love too.

As I already mentioned, there are new mediums and devices coming out that are abstracting the web and displaying the content in other more unique forms. Instead of the typical user sitting down at his/her work station and loading up Generic Browser X to “surf the web”, they are opening their Twitter client, geo-locating friends in an iPhone app, and soon to be reading books on their iPad.

Without trying to sound to cliche, the internet – and the data that supports it – is infiltrating our lives and dictating how we communicate amongst ourselves. Maybe “dictate” and “infiltrating” are harsh words, but when thinking about it from a newspaper publishers point of view, those words don’t sound harsh enough. It’s no question that the internet has hurt traditional print media publishers and the primary reason many of these companies have gone out of business. But my question is what aspect of the internet actually led to the demise? The answer is not that mind-blowing, but is simply, the accessibility of information became so abundant we no longer needed to pay to see the same content elsewhere.

At this point you might be saying “Wow, great concept, Bryant… ‘Accessibility’ – welcome to 2010,” and I will also agree that this concept is rather outdated, but it is also the exact point I am trying to make. Instead of saying “welcome to 2010″ you should have been saying “welcome to 2006.” Accessibility of information is what has already shaped the internet and is what made it into this giant creation that we use today. The frontier that is now being conquered, and is the root of the “abstraction” process I have refereed to, is making the web more usable.

When you look at some of the first products that “abstracted” the internet, such as Rich Internet Applications (RIA), it’s very clear that they wanted to take the content of the web and make it a more enjoyable and usable experience. Why is the internet not a usable and enjoyable experience? Ha! Well that can be answered several ways (and also very sarcastically), but in short it is because of the infrastructure of the internet. At that point in time (which we are arguably still living in) HTML and web browsers were not advanced enough to handle some of the interactions and display patterns designers wanted to use to display content. Because of this technological limitation, developers created RIA, which can grab the content of the internet and harness the power of a localized application to deliver it to a user in a much more versatile, running environment.

As powerful as some RIAs are, the main drawback is that it was not running inside the browser, the main component of using the Internet. However, with the adoption and implementation of new web standards into modern web browsers, browsers would soon be able to handle all of the same interactions and display patterns that RIA currently did.

Flash forward to today (You didn’t know we were in a flashback mode, did you?) where most modern browsers support forms of HTML5 + CSS3, and paired up with the canvas element, there are javascript techniques out there that will rival Flash. What is the next step? Well, it’s taking the usability and accessibility of the web and delivering it in a product smaller, leaner and more tactile than looking at it on your desk monitor….wah-lah – the iPad!

Now, I don’t consider myself to be an Apple fanboy, though it may seem like I am one when I talk about the iPad. But what I am really trying to explain is the concept and execution of the iPad. I don’t think any company has nailed the tablet concept quite like Apple – although I do think other companies definitely have the capacity to do so. Anyway, the reason I believe the iPad to be so revolutionary, is that it takes the accessibility of the internet, adds in usability features found on modern web browsers and couples the whole thing in a nice, lean well-designed mobile product. It’s the type of product that you look at old 1980′s movies and see futuristic people with flying cars using, except the main difference is that it’s actually here. Does the iPad not have multiple applications running? No. Does it have Flash? No. Does it deliver its most important asset, the internet, in a new portable textile medium? YES! And it seems to deliver that extremely well.

I must say that I was very disappointed when I learned that the iPad didn’t have a forward-facing camera. Furthermore, I think the price structure of the various iPad units suggests a bait and switch approach ($499, yeah but who is going to buy this without 3G?). But when it’s all said and done ,I would be more than willing to pay $650-ish dollars for a device that delivered the Internet to me in a portable, book-sized container.

And now, finally, back to the publishing industry. It would seem that with all this technology they are destined to go the way of the Dodo Bird, but if you take a closer look (at least at the iPad) you can see the iTunes store paradigm fitting in perfectly. iTunes itself has grown to be the world’s largest music retailer, and an argument can be made that people only download music that is easy to get, no matter if it’s free or .99 cents. Bringing this sales approach to the magazine and newspaper publishing industry would be a win-win….win. Publishers will still be able to provide their premium content to virtual subscribers and not have to worry about printing physical copies. Users will be able to access rich “print” media on new user-friendly devices that enhance the reading experience. And device manufactures will be able to create these new devices and push the bounds of technology even further.

Whew… that was a lot of writing, and maybe my conclusion is a little optimistic. But in the face of seeing a major industry collapse on itself, it is refreshing to see an outlook change and be reinvigorated by the advent of a new cutting edge piece of technology.

Among his many relevant points was the notion he referred to as ‘the dominance of search.’ Matt’s focus for the evening was specifically on sites that serve up social commerce, but I think the search issue is something any site needs to consider seriously. What Matt was referring to was his claim was that 50-80% of traffic across the web comes from search. This was a profound, yet not to surprising statistic when I heard it. However, in my experience, clients are not very proactive in doing everything they can to make their sites findable. As web designers we should take more responsibility in educating our clients on the importance of being findable. Traditional means of SEO such as embedding tags in code, writing bot friendly copy, etc. are still a great start, however the effectiveness of user generated comments/reviews of your service should not be overlooked.

Matt remarked that a quality review can, and will, bring in roughly 50 people to your site. At which point. if you do a reasonable job of converting those 50 people to buy (say 3 or 4%), one could argue that the person who wrote the review for you actually played a more valuable roll while they were on your site than if they had actually made a purchase! This view may be a little subjective, but the key takeaway is that the people who are using your software and are actually taking their time to participate in the social sphere are extremely valuable users. They’ll give you credibility, get others involved, and help you create meaningful content. They are valuable for many reasons, but if for nothing else, they’ll bring other people to your site.

“Will my users be able to find me through search?” is a question Matt proposed everyone who wanted to have a successful presence on the web, should be asking up front. In other words, get your clients on board with SEO right out of the gate! There’s no way around the fact that there’s an overwhelming amount of content online. Having a site that is cutting edge, cool, innovative, clever, refined, well planned, etc. will not make your software successful based on these factors alone. You have to be findable. For more on findability you can check out findability.org or Peter Morville’s book called Ambient Findability.

“A simplified view of what content will appear on each screen of the final product, usually devoid of color, typographical styles, and images…”

Wireframes can technically be generated by just about anybody. However it is painfully apparent when someone with little or no experience takes it upon themselves to do so. The classic example is when a client has some ideas they think are great and feels the need to express them. More often than not those ideas could be communicated through words via email or on the phone and it would be best to avoid wireframing on their part. A person without the training and skills required for effective wireframing is liable to produce incomplete or inaccurate documents that can harm the overall process if not fixed later by someone who is more experienced. Sometimes wireframe documents can look quite simple, but that does not mean that their purpose or the information they contain should be taken lightly. The information found (or not found) within has profound implications. Inappropriate page elements documented at early steps can produce results which reverberate throughout a project all the way through to launch.

Wireframes exist, in part, to communicate the various ideas that will make up the page. But they also are tasked with communicating the intended user’s experience (UX). The UX is like a big collective idea made up of all the individual ideas. Whenever the individual ideas are manipulated, the collective idea is affected. While it is desirable for many individuals to contribute to the individual ideas, it takes a trained professional to shape them all into the big idea. A project is delicate early on and I think there should generally be a single Information Architect (IA) to produce wireframes and their subsequent iterations to preserve the integrity of the UX.  The advantage of having a single purveyor of wireframes is that good information tends to get discovered and refined, while bad information is removed more efficiently. If the project is large enough to have additional IAs or the client insists on being directly involved then some standards should be put in place to avoid miscommunication and extra work. It may be a good idea to create a framework template as well as a basic elements library for all parties to share.

Good wireframes should embody an organized aesthetic, which is visually pleasing, yet neutral in emotional expression. This will help to communicate what is truly important: the ideas. Although wireframes are basic it still takes many years for an IA to develop their style. There is a methodology to creating these documents we all develop over time and seldom do we ever do it the same way as our peers. I would be interested to hear about instances from other UX designers who are responsible for producing wireframes  and hear weather or not they prefer to work solo or collaborate with their co-workers to produce final deliverables. Additionally, I would like to hear how other UXers feel about clients being involved as co-creators of wireframes speciffically. Perhaps some organizations have a sophisticated system in place which allows for and encourages this. To date, I have yet to see an organization with such a structure. Much of this article is based on opinions I’ve gathered from my personal experiences and those of my close pewers. Every designer and organization however is going to use a slightly different approach. I hope that there are others out there that can shed light on this topic for everyone to consider as well.

Some examples of  good wireframes with varying styles:

1. A splash page to allow the user to choose the HTML Site or the Flash Site.
2. A separate directory for the HTML Site to live that only Google would see.
3. A flash detection that would redirect the user to the HTML site if it didn’t have Flash, Google included.

None of these options were ideal. A splash page is a usability nightmare and putting the HTML site in a separate directory would still hurt users coming from Google results as the search engines would most definitely just send them to the HTML site, which defeats the purpose of having a Flash site in the first place. So instead we took some inspiration from Damien Bianchi at Adobe.com and put the HTML and Flash in the same directory using tricks to serve up the appropriate Flash content that cooresponded to each HTML page.

1. A splash page to allow the user to choose the HTML Site or the Flash Site.
2. A separate directory for the HTML Site to live that only Google would see.
3. A flash detection that would redirect the user to the HTML site if it didn’t have Flash, Google included.
4. Flash detection to serve up the SWF or the HTML in the same page.

Creating the HTML Site.

There were two goals in creating the HTML site.

1. Improve SEO Results
2. Have a Good User Experience Fallback for Users Without Flash

For the first goal it was just a matter of adding an HTML page to correspond to each “page” in the Flash version of the site. The HTML uses all static content, rather than pulling the content from the XML files the Flash version uses, so search engines won’t have any trouble reading it. We also took care to use the best practices for SEO HTML markup. That is, we used the appropriate heading tags, alt tags on images, etc.

The second goal was a little trickier. Flash is a great platform for smooth animations and unorthodox layouts. Thus, replicating its strenghts with HTML/CSS/Javascript can be a bit tricky. We put to use jQuery, a javascript framework, to make it a bit easier and reduce the heavy lifting of coding the advanced animations and DOM manipulation ourselves. We added in some various jQuery plugins like JScrollPane, jQuery Color Animations, and some other smaller ones to allow us to really replicate some of the cool things the Flash site did. Once it was all said and done we had a pretty good replica that forces you to look twice and even caught some people around the office here off guard at determining if the site if Flash or not. Once we knew it was hard to tell we figured we had created a pretty comparable user experience in HTML.

Adding the Flash SWF to the HTML Site.

Once the HTML Site was completed we had to add the SWF of the Flash Site to each HTML page. We wanted the site to have the HTML be static and the flash to replace it if the user had it installed. So we used SWFobject 2.0 to detect if the appropriate Flash version was installed and SWFobject replaced the container div of the HTML with the SWF file. Voila, we have all the benefits of HTML SEO with all the benefits of Flash. Now all we had to do was get the SWF to load the appropriate “page” depending on which HTML page it was on.

Adding FlashVars to Load the Appropriate Page and SWF Address

Since the Flash SWF loads on the homepage by default we had to find a way to tell the SWF that it wasn’t on the index.html page, but it was, for example, on the contact.html page. We added some simple FlashVars to each page with SWFobject to communicate with the SWF what page it was on. They looked something like this,

Hey everyone, it’s Ryan ….I secretly hacked in to Steve’s account and am posting in his newest blog. I’m kidding, as was the case with our Flash / HTML website integration, we’re gonna tag team this blog post like the Legion of Doom. I’ll help to shed some light on how we got our flash and HTML to play nicely together.

As Steve mentioned, we  used flashVars to pass in a page value (or string if you want to be exact). What we were really trying to accomplish was coming up with a universal link, that could be used outisde of the website, to funnel people in (regardless of what technology they may or may not have). We simply check the users machine for flash with swfObject and then serve them the best available technology (flash or HTML).  If it was flash, we used the flashVars string to help flag the correct page to  be displayed. I’m sure you’re sitting there thinking, how? Well it’s your lucky day, I’m about to explain how we went about accomplishing that.

For those familiar with swfAddress, this code should look familiar to you…..

*****just as a note, the code plug in we’re working with isn’t friends with the ampersand. && should simply be ‘&&’. I’m sure most of you caught it but I just wanted to point it out to avoid any confusion. It should be ……. if (_currentframe == 2 && value == ”).

If the current frame = 2 and the swfAddress JS is suppying a blank value, it just forwards you on to the next frame (which is the homepage). If it’s value is defined, it skips to that page. Easy enough right? Well, the dilemma was how could we get this to flag what page we wanted with a flashVars value without disrupting how the function would work throughout the site? If you haven’t noticed already, that SWFAddress.onChange function only appears once in your flash code and the flash platform allows you to “re-use” it by simply making a basic call to it ….like:

The function on frame 2 sends the ‘about’ value through the onChange function and spits the user out on to the about page. If we wanted to modify that main function, we could be doing (and did on several occasions ) some unforeseen damage to how the swfAddress will / would be able to function (beyond the home page). Obviously, we didn’t want that to be the solution for our end product. This really became one of those situations where it was just inevitable that we would really over think it before coming to a final conclusion. After a few random trial experiments, we unscrunched our foreheads, started laughing and realized how insanely simple this actually was to accomplish. So what was the solution?

We added a new key frame to the timeline (inbetween the swfAddress.onChange function and the home page). Well, it wasn’t THAT simple. Instead of just forwarding the site on to the home page after it went through that conditional check (if it had a blank value), we just ran it through a sifter so to speak. If it had a blank value, I wrote a switch statement that would match the HTML page’s flashVars value to it’s intended page inside the flash movie. When it flagged a match, it changed the swf address value and forwarded it on to the desired page (i.e. if the flashVars value was ‘contact’, we forwarded it to the contact page). Here’s an example of what I’m talking about…..

The reason this works is that there’s only one occasion where the functions if / else statement forwards on to the next frame? Anyone have a guess? When the page is initially loaded (aka doesn’t have a swfAddress value). Any other time it bumps down in to the else portion of the conditional, drops it’s page value off at the coat check and gets forwarded on to that specific page inside the flash movie by swfAddress (like it would if someone pressed a button inside the movie). The only time our function will ever be triggered is when the page is loaded and that’s exactly how we wanted it to be. Any other time the frame is skipped over by the function on the previous key frame.

Hopefully that all made sense. Here’s the listed steps if you got lost:

1.) Express a flashVars value in your HTML. In our case, we used a string of letters.
2.) Use swfObject to check for flash.
3.) Use swfAddress to generate unique deep links.
4.) Add in a new keyframe between the sfwAddress value check function keyframe and the homepage keyframe.
5.) Write a switch statement on your new keyframe that takes the flashVars value and matches it to it’s existing page in the flash movie.
6.) Test, test, test.

Aside from the listed steps / examples, one place I would guess people will get hung up on is getting the added function / switch statement to move on to the home page (if that’s the desired effect). There are several ways you can accomplish it, so don’t over think it. I chose to just make the default state in the switch statement a play(); command.

Easy enough right? You could also supply the index.html page with a flashVars value of “home” or “index” and check for it specifically. Either way works, so use which ever one you prefer.

If you have any specific questions, post them in a comment and we’ll try to get back to you. As always happy flashing!

37signals.
37signals started phasing out support for ie6 starting in October 1, 2008. They’re not stopping ie6 users from logging in and using their software all at once. They’re taking the phase out approach of telling everyone that any new improvements or fixes may not be compatible with IE6.

Facebook.
Facebook has decided to provide an inferior experience and a large warning message to all their users in IE6.

Apple – Mobile Me.
Apple touts Mobile Me as a desktop experience on the web. Thus their site pushes far beyond what developers can even do on IE6. IE6′s slow javascript engine would just end up with too bad of a user experience for Apple, so they don’t even let you log in with IE6.

Notice the ugly transparent png apple logo

One thing these websites have is that they’re not even websites, they’re web applications. They, like many desktop applications, are starting to require a system upgrade to use their software. Users tend to me more understanding when it comes to an application asking them to upgrade than it does a website. We do it all the time on the desktop and this helps these developers get away with such bold actions. The other thing that separates these sites from most is they’re actively developed large applications. So they have new features, design iterations, fixes, and enhancements constantly, and as the web moves forward and IE6 stays so far behind it’s becoming more expensive and time consuming to try to retrofit things to work in IE6. What was financially feasible 2 years ago is no longer today. It had to start sometime, why not now?

Well if web applications killing support for IE6, what are web sites to do? First off, they don’t have the advantage of users tolerating a required update like applications, and they don’t always have the constant development iterations that web applications have, forcing them to kill IE6 for financial reasons. This hasn’t stopped a few others from taking an anti IE6 approach.

Finn.no
One of the largest sites in Norway, Finn.no has dropped support for IE6 and initiated a campaign to get others to follow suit. In fact they saw results of less ie6 users immediately which they’ve interpreted as people upgrading.

45Royale.com
45Royale is a respectable web agency that decided to offer a one IE6 page watered down version of their site to anyone using IE6. The site is very careful to let people know they’re only seeing 9% of their website and offers links to download a more modern browser.

So what does this mean for Billups Design? Currently we’ve worked hard to make the IE6 user experience of BillupsDesign.com as close to other modern browsers as possible.  We use a respectable level of ajax effects, transparent png and advanced CSS layout techniques, all of which we’ve tried to degrade gracefully for IE6. Do we keep putting hours of labor into supporting this one browser when the gulf between it and “modern” grows wider each day?

We’ve decided to take on a little IE6 experiment of our own. Since relaunching our site we’ve been actively pursuing feedback. With feedback comes iterations, and with iterations comes the decision to support IE6 or not. Our Google Analytics stats show that we’re getting about 4.7% of our visits from IE6 users. Thats about 1/20 users with IE6. Its a small percentage, but still a decent size. So we’ve built  a one-pager (a la 45Royale.com) to serve up to anyone visiting billupsdesign.com in IE6. We took a similar philosophy to mobile web design and filtered out all but the most important aspects of our site into the one page. You can check it out at billupsdesign.com/ie6/ .

Further reading:
http://www.bringdownie6.com/bring-down-ie-6.html

http://dearie6.com/

When I jump in to a project I’m really excited about, my patience (as a developer) is typically at an all-time low. I have always felt like (and sometimes still do) that I’m in a race against my own ideas. The longer I leave them in my head or on a piece of paper, the less likely they are to become reality. This type of mentality inevitably leads to the late night coding sessions that all developers, at one point or another, experience. You know, the ones that single-handedly keep your favorite late night coffee chains in business.

While I slowly developed a basic understanding of a lot of abstract concepts, what really gave me a lot of problems early in my flashing endeavors was taking that abstract concept and applying it to something practical. I understood, in it’s simplest form, why something was being done but I really struggled with taking that basic blanket concept and then plugging it in to one of my projects.

For one reason or another, understanding how to create a basic fluid flash layout really was a thorn in my side. I would find tutorials here and there that kind of taught me what I would like to know but the examples and explanations really left me with one or two questions that ultimately made me scrap the idea and move on to something else. After reading through some recent message board posts, I thought this might be a worthwhile topic to write about for some of the newer flashers out there. I would also encourage experienced developers to give this a read and add anything else (via comments) that might be worthwhile for anyone out there looking for a better understanding of fluid layout concepts.

As always, if you’re just starting out PLEASE don’t just rip through this post and download the source files. Why? Cause they’re not there. Trust me, I’m just as impatient as the next guy when it comes to this kind of thing but the most important part of learning development techniques is to fight the urge to just grab a file and try to use it (without understanding exactly what’s going on). I’ll do my best to explain things as thoroughly as I can and if you have questions on this subject, feel free to post it in a comment.

With all that said, lets get started……

————————————————–

1.) The first thing you need to do is create a new AS3 document in Flash. I’m going to assume that if you’ve got to this point in the blog that you can do that on your own but if not, here’s a hint…… File > New > Flash File (Actionscript 3.0) > Click OK.

2.) Open up the actions window (Window > Actions) if you haven’t already and lets add some code. ***In the spirit of learning, I’m not going to type out this code. I will prove screen captures for you to follow but a big step early on in the development learning phase is physically learning to type out your own code (and making it a habit to do so). If you don’t cheat yourself early on, it will really payoff later down the road as you continue to build applications / websites. Copying and pasting is convenient but it won’t help you learn as quickly.

With all that said, lets add some code…..

3.) The first thing we’re going to do is add an event listener, in this case Event.RESIZE, to the stage. This will allow us to track when a user modifies the size of the stage and act accordingly to adjust the elements that live in / on it.

To do this we’ll assign the (Event.RESIZE) event to the stage property via an event listener (stage.addEventListener). This is going to dispatch an event whenever a user does anything that modifies the height or width of our published flash document.

To add an event listener we first express the instance we want the event attached to (stage), what we are going to attach (.addEventListener), the type of event listener (Event.RESIZE) and the function we are going to trigger when the stage is resized (onResizeStage). If you have done it correctly, your actions window should look something like this:

Add your event listener.

Next, we need to write our (onResizeStage) function that is fired by our (Event.RESIZE) listener. Then, we can put our trace statement inside it and track when the stage is re sized and what it’s updated dimensions are. We start writing a basic function in AS3 by using the reserved word (function). We then give the function a name, in this case (onResizeStage). I’m sure you’ve noticed the function name is the same as the one we expressed in the stage.addEventListener(Event.RESIZE, onResizeStage ); event. That’s because we want that function to be fired when the (Event.RESIZE) event takes place.

Next, we asign a variable name (evt:) to the event object and then express the type of variable it is…in this case (Event). If this doesn’t make sense to you, I would suggest reading about some more basic AS3 practices on Adobe LiveDocs. Lastly, we tack on :void, as the function is not going to return any information and open and then close it with our brackets / curly braces {}. Your function should look like this:

Write your (onResizeStage) function.

4.) We want to take the information that the function (onResizeStage) outputs for us and use it to reposition our objects. To show you how the (Event.RESIZE) listener works, lets plug in a trace statement to get some feedback in the output window. Tracing is simply a way for you to get feedback from Flash and it really is a great tool for testing. It will return requests to the output window and help you to understand exactly how this RESIZE function works. I would expect most of you know how to type a trace statement but if not, I’ll break it down as best as I can.

5.) Since we’re interested in adjusting an instances position based on the height and width of the flash movie, lets trace the height and width of our flash movie and watch how our RESIZE event handles it.

Inside the brackets of our (onResizeStage) function we’ll type trace(stage.StageHeight, stage.stageWidth). Anything typed in “quotations” in a trace statement will display as static text. It’s good practice to label what it is that you are tracing (with a static label) inside your trace statement. Why? Well, let’s do it without a static label and you’ll see why it’s advantageous, especially in a larger project, to thoroughly comment / label all aspects of your code.

Inside our (onResizeStage) function, let’s type the following:

Write your trace statement.

Now, lets compile it and look at our .swf. You should just be looking at a blank white screen (as we haven’t added any objects to the stage). If you do something to affect the height or width of the .swf, by maximizing it or dragging it’s edge, you’ll notice two numbers are being displayed in the output window when you let go of the mouse. One number is the height and one is the width. Which one is which? Well, do you remember which one went in to the trace statement first? Even if you do, you can see how this can be really confusing without a relevant label.

Let’s put in a label and recompile our .swf.

Insert labels in to your trace statement.

As I mentioned earlier, quotations allow you to add text that the trace statement will simply display in the output window. The key difference (quotes vs. no quotes) being that it displays it in the output window without carrying out an actual operation (such as retrieving the height or width).

We simply concatenate (add a + sign) to the strings we want the label to be associated with (ie. “Stage Height = ” + stage.stageHeight). We then label stage.stageWidth as well (“Stage Width =” + stage.stageWidth). It’s good practice to separate statements that are being traced by a coma. Why? Because it helps make things consistent and a lot more readable (for you or someone else that may work on the project). It also helps formatting in the output window, as a coma will insert a space in between multiple statements.

You could theoretically concatenate string after string (“Stage Height = ” + stage.stageHeight + “Stage Width =” + stage.stageWidth) but your output is going to be Stage Height = 415Stage Width =572 instead of Stage Height = 415  Stage Width =572. It’s a small detail but a good note on best practices.

6.) Now we have a better understanding of what’s going on with the RESIZE event and our triggered function, lets do some layout basics (finally!).

The first step is adding a few lines of code to let flash know we want to turn off / on a few default properties of the stage. The point of a fluid layout is to use the height and width of the stage to establish new layout positions and NOT to zoom in out / skew the movie clips, buttons, etc. To ensure objects are going to slide (left / right, up / down, etc.) in position and not scale up or down in size, we need to turn scaling off. This will allow our objects to move according to the stage width / height and not scale (50%, etc) as the stage gets bigger or smaller. To do this, we’ll simply type the small code snippet below:

Specify stage properties.

Now, for our last bit of code before we start adding some elements to the stage…..

The final little piece of code we need to express is to let flash know that we always want our movie to align to the left of the browser window. This ensures things anchored to the far left will stay on the far left and not reposition if the .swf file contained in our HTML page were to move. To accomplish that we simply set the stage to align to the TOP_LEFT.

Specify stage alignment properties.

7.) Still with me? Now lets create objects to drop on to our stage. We’ll start by making 2 separate movie clips, both 80px by 80px.

They can be any shape you’d like but for this exercise, I’m just going to make some colored squares (one blue, one red). Take the Rectangle Tool (R) and draw a blue box and a red box. Convert each one to a movie clip. You can do this a number of ways (key board short cuts, etc) but for this exercise go Modify > Convert To Symbol and then give them names of boxBlue and boxRed.

***An important note here…..make the registration point the top left corner (see image below). Why? Because it’s much more flexible (in my opinion) then just centering the registration point. It causes you to have to do a bit more math when resizing a centered object but I’ll explain why it’s worth it in the long run.

Convert your vector squares to movieclips.

Now, click on the boxes on the stage and give them instance names of boxBlue and boxRed in the property inspector. This is so they can be referenced by the actionscript code we’ll write.

Give your movieclips instance names.

Just to make sure we’re all on the same page, your actions window should look like this:

Double check your source code.

8.) The first fluid alignment I’ll discuss is centering an instance. For this first example, lets use our boxRed movie clip.

Now is where a little basic math comes in. To find the center of anything, you simply divide the width and height by 2. In our case, we want to divide the width and height of the stage to find the middle point at which to center our boxRed movie clip. The main thing we want to accomplish is re-centering our boxRed movie clip when the stage is re-sized. To do this, lets place some code inside our (onResizeStage) function.

Source code to center your boxRed mc.

***You might notice the grayed out text above. If you don’t recognize why that is, it’s because I commented it out with two // so it would no longer continue to trace the height and width of the stage. You could remove it all together but it’s good practice to leave important trace statements intact, just in case you need to trouble shooot (again) later in the project.***

Go ahead and compile your flash movie. If you re size your .swf movie (or the web browser, depending on how you prefer to preview your flash files) you’ll notice that the boxRed movieclip will adjust as the browser adjusts and the boxBlue movieclip will simply stay put.

You might look at it and say, why does it not look centered? (If not, you may need to fine tune your eye for document layout. ) I’ll explain (and illustrate) why that is. If you remember, earlier in the tutorial we specified the registration point of our movie clip(s) as the top left of our vector shape. So dividing the stage width and height (and adjusting the x and y of our movieclip accordingly) will simply center the top left corner of our object on the stage (see the figure below).

Centering result vs. expected outcome.

The expected out come was (fig 2.) while our actual result was (fig 1.). Now, before you go rushing through your file to change the registration point (to be the center of our object) or re-align the vector object to the center of the movieclip’s stage, let me explain why doing that is not that great of an idea (in my humble opinion).

By making the registration point of a movieclip the top left, it allows a designer (or developer) to layout objects on a typical (x, y) axis. If you have a movieclip with several different elements embedded in it, your movieclip’s stage will function as the main flash stage would (with 0,0) being the (x,y) coordinate of the top left of the stage. Maybe this doesn’t seem like such a huge advantage but let me illustrate the point to really drive it home. The figure below shows how you would have to align a second movie clip if your registration point was in the center of your instance.

Potential layout issues with a center registration point.

If you center your movieclip’s registration point, the (x,y) of your second element would be (-35, -35), instead of simply (5,5). I hope you can see how that could get incredibly confusing if you’re trying to attach objects at run time or trying to consistently produce precise spacing in your imbeded objects.

If you’d prefer to center the registration point of your objects, then please do so. There’s not really anything wrong with it but it’s just my personal preference that using a top left registration point is much more advantageous, especially once we start talking about other aspects of fluid layouts (scaling an elements width, scaling an elements height, etc, etc.). Just be prepared to potentially have to do some extra math if you’re centering your registration points. I can only make a suggestion on what I consider to be best practice…..in the end, do it whichever way you’re more comfortable with but keep in mind the rest of this tutorial (past centering objects) will not include math fixes for objects that have a centered registration point.

Ok, so the question is…..how do we fix it (create an offset so the object displays in the absolute middle of our window)? It’s pretty simple really.

As I explained earlier, you find the center of an object by dividing it’s width and height by 2. Our boxes are 80px by 80px. So we’ll divide 80 by two (in both cases) and get an X offset of 40 and a Y offset of 40. So, now on to the part some might find tricky……applying it to our equation so we get the desired result.

Based on the basic principles of a top left registered (x,y) grid, if you add to the x and y numbers it will move it right on the stage and down…..if you subtract from the x and y numbers, it will shift your object left and up (which if you look at the illustrated figure above) is the desired result we are looking for. So, all we need to do is subtract 40 from the center of our stage.

With all that said, lets type:

Add your offset.

Now recompile your FLA and adjust the size of your flash movie.

You’ll notice we get a much more precise result and the movie clip doesn’t appear to be off-center (now that we have compensated for the x and y offset of registering the movieclip on the top left). Easy enough right?

The reason I recommend doing it this way is that in almost all cases, you’re going to want a movieclip registered in the top left for the other effects i’ll go over. It’s easier to compensate for it on only a centered object than to compensate for it in every other iteration / alignment. I hope that makes sense and if it doesn’t, you should see why later on (when we start adding some more alignment solutions to the project).

Let’s finish off centering up an object with this last tip…..

Some of you might be asking, why doesn’t the movieclip center when the .swf file first compiles? Well, hopefully you have already realized why (because it only assigns a new x and y value when the stage is re-sized) but if not, I’ll give a (very) brief explanation. Flash has to be told what to do. A program like flash is only as good as the directions a programmer gives it and if you don’t give it any, it’s not going to do anything. In this case, it’s just assigning a default (x,y) value for our boxes (i.e. where they are placed on the stage inside our FLA) because we didn’t give it any specific directions to do differently. Let’s fix that so our object not only realigns in the center of our window on re-size but starts there from the beginning.

All we need to do is grab the .x and .y equations we just wrote for our boxRed movieclip and paste them outside of our (onResizeStage) function, just below our stage.scaleMode amd stage.align instructions. This lets flash perform the equation when the movie first loads and also when the stage is re-sized.

Make sure your code is both inside and outside of our equation.

Now recompile your FLA and your boxRed starts in the middle and stays there as the browser / window re-sizes.

If your head hurts, I understand but try to bear with me or better yet, take a break and come back to this point. If you’re stuck or having trouble getting your code to work, here’s what your actions panel should look like:

Double check your code.

You’re probably thinking, 13 lines of code?! 13 lines of code!? I know, it can be somewhat frustrating that something so simple could take so long to explain but understanding the basic fundamentals of many of these concepts will apply across a multitude of other projects you are bound to take on (both willingly and unwillingly). Understanding the fundamentals of why something does (or doesn’t work) will really help you problem solve (on your own) down the road. In the end, figuring things out by yourself is one of the most rewarding aspects of programming.

With all that said, let the impatient crowd rejoice…..the next few examples will be much faster paced but I will be sure to hit on all side info relevant to how the concept works.

9.) The next fluid alignment we’ll touch on is adjusting the width on an object to the browsers / .swf files width. This is especially helpful when creating navigational elements, such as a background color that might sit just behind your nav text / buttons and scale full width to the browser.

This only takes 2 more lines of code (yay). In this case, we’ll grab our boxBlue and use it for this example. Position it on your stage at (0,0) and add the following code (one line for when the movie initializes and one line for when the stage / browser is resized…..just as we did with the boxRed movieclip):

Adjusting an mc's width based on the stage's width.

A friendly reminder. Make sure you double check that your line of code appears both inside and outside of your (onResizeStage) function, just as we have done for all the other steps. If it doesn’t, copy and paste it in to the appropriate place.

The above concept is a simple one. We want the width of our blue box (boxBlue) to be the same as our stage. We calculate the width of the stage with the stage.stageWidth property and apply it to our box (boxBlue.width = stage.stageWidth;). When you recompile your .swf, you’ll notice that the width of our blue boxes stretches with the stage.

10.) Next up, right justify.

We’re gonna have to make a new box for this one, as we want to retain what we’ve already done. Lets make another 80px by 80px box. This time, I’m going to make it Orange. Once you have made an orange box, convert it to a movieclip, top left justify it’s registration point and give it an instance name of boxOrange. Done? Lets write another small snippet of code (again, just 2 lines).

Right justify an mc based on the stage's width.

Another friendly reminder. And yes, again! Make sure you double check that your line of code appears both inside and outside of your (onResizeStage) function, just as we have done for all the other steps. If it doesn’t, copy and paste it in to the appropriate place.

Here’s where the left registration point comes in handy again. To position our moveiclip to float on the right side of our stage, we simply use the stage.stageWidth property and subtract the width of our object (80px). That 80px offset simply bumps our object 80 pixels to the left of the far right edge of the stage. I hope all this is starting to click in your head now and you’re thinking of different ways you can position / anchor things on the stage.

11.) The last alignment solution I’m going to go over is aligning something to the bottom of the browser (i.e. something like a footer).

Lets make another 80px by 80px box. This time, I’m going to make it Green. Once you have made an green box, convert it to a movieclip, top left justify it’s registration point and give it an instance name of boxGreen. Give it a x value of 0, so that it aligns to the far left of our stage.

As a side not, I would start getting in to the habit of doing this programmaticly by simply typing boxGreen.x = 0; I decided to skip those steps in an effort to keep this tutorial as lean and mean as possible (but just wanted to mention it somewhere). I would guess most of you are already doing such things (without instruction) but I wanted to make sure I gave it a brief plug.

Again, once you understand the basic principles of what we’re doing right now, you should find it fairly easy to not only understand these basic concepts but also to implement more advanced ones in your projects.

To align something to the bottom of the movie and stretch it to to the width of the stage, we’re only going to need 2 lines of code. 1 to adjust the width and 1to adjust it’s y position in relation to the stage’s height. Easy enough right?

Let’s crank out the last few lines of code (I know, it’s about time) for this!

Aligning an mc to the bottom of the browser window.

Psst. Make sure your code appears both inside and outside the function. Sorry, I had to.

Congratulations! Not because you’re done but because this (next short info blurb) is the last small explanation you’ll have to plod through.

I have confidence that most of you thoroughly understand how this is now working but just in case there is someone out there looking for this last bit of instruction, I’ll explain why I’m doing what I am to get our desired result.

The stage.stageHeight property returns the size of our stage, as it appears in the browser. Because we want our object to hug / appear at the very bottom of the stage, we simply use that number and subtract the height of our object. Why do we subtract? Because in a traditional (x,y) grid you subtract to move up, add to move down…..because our object is justified in the top left corner, we need to subtract it’s height or it will be aligned at the bottom of the stage, out of view. If you are having trouble understanding this concept, just remove the (-80) on the equation and recompile it.  It will appear as the object disappeared but really it’s just aligning the leading top edge of the movieclip to the very bottom of the stage / browser window (fig 2.). See the figure below for a visual representation. The colored red area is off of the visible part of the stage inside the browser.

-80 offset explained.

12.) If you’ve got to this point and didn’t get everything to work, here’s the final code sample posted below. Hopefully you didn’t have any problem following along but if you did, compare your actions panel to the one below and see where you got tripped up.

Final source code.

13.) The last step in all of this is changing the height and width listed in our HTML file. Flash publishes a pixel by pixel output in the HTML file it spits out that relates to the document size listed in our FLA file. Because we want the stage to be equal to the height and width of the browser we just need to make one quick change. Instead of having our height and width be in a pixel format, we simply want it to display to 100% of the browsers width and height.

Our specified height and width appears THREE times on the page, so don’t miss one set…..it could cause problems down the road depending on what browser the end user is viewing your project on. If you need specific directions you’ll find it once in the AC_FL_RunContent function and twice in the object id tag.

Change the height and width settings in your HTML doc to 100%.

One last fix……….

By default, a margin of 10 pixels is sometimes assumed. To turn those margins off, so our file hugs the endpoints of our browser, we just need a short piece of CSS. Include this just before the close of your HTML page’s head tag:

<style type="text/css">
<!--
body {
margin-left: 0px;
margin-top: 0px;
margin-right: 0px;
margin-bottom: 0px;
}
-->
</style>

If you’re having trouble with this part, just view the HTML source in the working link posted below.

For a working example of how your file should look, click here to view my final tutorial .swf file. Resize the window and our objects are sliding / scaling as they should. hopefully your file looks exactly the same! If not check back soon (see my p.s. note) as this will most likely be an ongoing tutorial subject that I update with newer blog entries.

Cheers! and as always, happy flashing!

Ryan

P.S. If there’s a large request for source files, I will post them a few days after the blog has gone live. I’ll also swap out the images with source code……..BUT until then, invest in your professional skill set and learn how and why you’re doing the things you are.

EDIT: Commented source file can be downloaded here.

Steve Krug discusses doing usability testing with 4-6 people about once a month can lead to solving problems typically yield big efficiencies and return on investment. We wholeheartedly agree, Steve!

iPhone apps are proliferating like so many bunnies in a vast green meadow. To this point, the overwhelming majority of these new apps are for entertainment, utility or novelty. However, commercial applications are only around the corner. Here at Billups Design, we’re working on commercial applications for the iPhone that our clients and prospects can procure to advance their online communications. Until that time when private enterprise awakens to the uses of iPhone apps, we’ll just have to have fun using our phones for things like this: The Rubik Cube Solver.