I was approached by Preferred Wound Solutions to help create their website and one of the first things we targeted was their logo. They weren’t interested in a complete overhaul as they had promotional material printed with the old one, but they definitely were in the market for a new look.

If you’ve never embarked on this process, it may have been because it seems daunting. I didn’t want and they couldn’t afford a long draw-out process so I put my thinking hat on and came up with some progressive worksheets that ended up working very well.

Step 1: Style – Discover the right style for the logo. For this, I offered a three-step process that helped them decide the critical elements of the logo.

Style Worksheet

As you can see, they were to choose a dot style, a text style and a background (if desired). The result of this, which only took a few hours for them to decide, helped us move to Step 2 – Color. This resulted in a new worksheet based on their desire for a “brighter orange” to be used as well as their results from the style worksheet.

Color Worksheet

From this, something interesting happened – they chose the entire color palette for the site. I knew they had blue in their original logo and I didn’t want to totally abandon that color so I threw some of those options in for good measure. In similar fashion, they came back quickly with their logo choice, but requested another dot configuration and asked to see them side-by-side in their final colors. A “finalist” worksheet was then developed.

Finalist Worksheet

We are sitting pretty now – and it is all right there in one place. This, as it turns out, was a crucial step as their final choice was #2 above – the last-minute dot config.

All in all, this was a great process for both client and designer. It was clear, clean and provided a very visual client the needed options to decide quickly.

In summary, here are the principles I took away from this experience:

• Focus on one aspect at a time | The tendency is to do color and style and palette all in the same step, but by forcing each aspect to be decided on in order, it helped remove some of the clutter from the process
• Give them enough options to make it complete, but not so much  as to overwhelm them. What you’re after is a balance to allow for your client to move to the next step with one or two candidates that can be explored in the next step.
• Be quick | This process is pretty exciting to the client and I felt an anticipation for the next step, so I moved very quickly on each successive worksheet so that emotion could carry over and keep the process rolling along.
• Add some style | This is also a great time to showcase some design skills you have. Little things like palette swatches and dotted lines make a difference and can improve the relationship as they will be able to see that you care about your craft.

There’s nothing magical about this process, but I was amazed at how well it worked and I’ll definitely be using it in the future.

If you want to follow the progress of how this translates into a website, be sure to bookmark www.preferredwound.com

SWFObject has been around since October 2004 as a JavaScript method to detect not only the presence of the Flash Player, but minor versions of the Flash Player for feature readiness. Since then, it’s evolution has continued to add features that cover today’s ever-increasing code complexities. To get the SWFOjbect code as well as all other resources for this very useful tool, head over to http://code.google.com/p/swfobject/

As I stated in the overview article, this is my preferred method for Flash detection for the iPhone. This method is used on all of your SWFs and therefore inherently takes care of all detection and alternate content substitutions as part of the solution. In short, it’s simpler.

Obviously, the first thing to do is download the code and get it on your site. There are great instructions on the Google site on how to setup the include files and you also get some demo files that show how your code should look when using either the static or dynamic method.

I used hyper-linked images that looked similar to the Flash content as the alternate content so visually, there wasn’t much missing. Other than that, there isn’t much to it other than following the instructions and choosing the method that suits your content and situation better. There will probably be some trial and error that you’ll need to go through, but given an hour, you should have it just like you want it.

Here’s the JavaScript code on my example site (put inside <head> tag):

<script type=”text/javascript” src=”/Scripts/swfobject.js”></script> //the include JavaScript file
<!–Button 1 Code–>
<script type=”text/javascript”>
var flashvars = {};
var params = {};
params.wmode = “transparent”; //sets the SWF file to have a transparent background. Default is “opaque”
var attributes = {};
swfobject.embedSWF(“/assets/multimedia/PTT_Button1.swf”, “myContent1″, “174″, “40″, “9.0.0″, “”,  flashvars, params, attributes);
</script>
<!–Button 2 Code–>
<script type=”text/javascript”>
var flashvars = {};
var params = {};
params.wmode = “transparent”;
var attributes = {};
swfobject.embedSWF(“assets/multimedia/PTT_Button2.swf”, “myContent2″, “174″, “40″, “9.0.0″, “”,  flashvars, params, attributes);
</script>

And the associated content code (alternate content defined):

<!–Button 1–>
<div id=”myContent1″><a href=”html/FindTip.asp” style=”padding:4px”><img src=”assets/images/PTT_Button1.jpg” alt=”Defeat the Diaper | Find a Tip” width=”174″ height=”40″ border=”0″></a></div>

<!–Button 2–>
<div id=”myContent2″><a href=”html/GiveTip.asp”><img src=”assets/images/PTT_Button2.jpg” alt=”Defeat the Diaper | Give a Tip” width=”174″ height=”40″ border=”0″></a></div>

Given that, there is one piece of advice I can give:
Make sure you enclose the content you want SWFObject to examine in <div> tags. For those of you that code using tables, don’t try to affect a <td> as the SWFObject’s default behavior is to hide the element and this will destroy the table’s structural integrity and therefore produce undesired results.

For an example of a site that this method has been used, you can go to defeatthediaper.com – my community potty training tip site. I hope this helps and don’t forget to add the <meta> and CSS mods outlined in the overview article.

When you publish your Flash content, you have the option of publishing HTML and in the associated option for HTML publishing, there are several check-boxes related to which version of the Flash Player you want to target and whether or not you want the resultant HTML to check for the presence of the specified version or above. FIG. 1 shows what you would check to get the HTML file that checks for the presence of a version of the Flash Player.

FIG. 1

Provided you check the box shown in the figure and publish your content, you’ll get an HTML file that has the detection code in it. As you examine the code, you’ll see that the detection script looks for a specific minimal version of the Flash Player, not just the presence of the Flash Player. So, the detection script can “fail” for two reasons: 1) An insufficient version or 2) the absence of the Flash Player altogether.

Therefore it is a good practice to include the GetFlashPlayer icon linked to Adobe’s site in case they were sent to this page because of a version problem and not the absence of the Flash Player. I guess you could use the CSS mod outlined in the overview article to hide a <div> tag that includes the icon if you don’t want your iPhone users to see something they can’t act on.

The next step is to copy all of the detection code including the conditions to another HTML page and save it as the site’s default page – typically index.htm or default.htm. From there you can send your users to either the regular home page (successful detection) or an alternate page (failed detection). The alternate page is where you can customize an image-based version of the home page that can be seen by mobile browsers that don’t support the Flash Player as well as explain why they were sent there.

I then went a step further and set a session variable and checked it on every other page on the site that had Flash content so I could either substitute alternate content or hide the Flash content altogether. This has an inherent problem as the session will at some point time out and if the iPhone user closes Safari and comes back, they could be faced with a site that doesn’t know they are a non-Flash user.

To overcome this, you could call a modified version of the Flash Detection script on each of those pages that resets the session variable if the detection fails, but that starts to get pretty cumbersome and is why I eventually went to the SWFObject route. You can read about that method in THIS POST.

To see a site that uses this method, go to www.americanpiepizza.net – a Central Arkansas pizza joint with a killer menu.

Two different strategies were employed and I thought it might be fun to share them. The first is based on a technique I’ve been using for years via simple Flash Player detection. The second, uses SWFObject 2.2 and displays a non-Flash equivalent of my Flash elements for any user without an active Flash Player. Each have their merits; their pros & cons and therefore it is up to you whether or not they fit your situation.

I’ve even found a third that uses Regular Expressions to detect the use of a mobile device and redirect users to alternate pages. I decided to reject this approach because I don’t want to maintain multiple versions of my content for a given percentage of users – especially when there are alternatives for almost all scenarios. If you want to know more about how to detect mobile devices for a variety of platforms  via regex, visit http://detectmobilebrowser.com

Regardless of the method, there are two things you need to do for iPhone users. One is a META tag that needs to be inserted into your pages and the second is a CSS style inserted into your style sheet. Here are some examples:

META | The WIDTH value is whatever width your actual content container happens to be
<meta name = “viewport” content = “width = 960″>

CSS | Because the iPhone uses a full version of Safari, the device type isn’t “handheld” – it is screen, just like your laptop computer. Apple didn’t want their users to get the handheld versions of websites, but rather enjoy the full version of the site. So, adding a new CSS file with the “handheld” designation won’t change the appearance of your site on the iPhone. I’m not saying that you shouldn’t develop a handheld version of your CSS as part of your usability strategy, but it won’t do anything for your iPhone users.

Make this the last entry in your CSS file. As you can see, I’m overriding several styles if the screen width has a maximum width of 480px. Put whatever styles you need in here to make the iPhone version readable.
@media only screen and (max-device-width: 480px) {
body,td,th {
font-size: 12px;
}
.page-content {
line-height: 22px;
padding: 4px;
color:#FFFFFF;
font-size:16px;
}
}

If you’re interested in the Flash Detection method, read THIS POST outlining it. If you’d rather employ the SWFObject method, I’ve covered it in THIS POST.