Know Thy Target Audience

I have been on a quest to find the perfect iPad case/protection system. This has been no easy task, given the wide array of products out there; from very conservative looking leather folios to funky slip sleeves and everything in between. Alas, this is not a post about the destination, but that of discovery.

During this time I have visited many websites, some generic, that happen to sell iPad accessories, to those of boutique firms that cater, almost exclusively, to the Apple user. The specialized sites either sell or market all manner of protection exclusively for the entire line of portable Apple products. No other portable product line is addressed. This is reason for this post.

These sites were presumably designed and developed by those in the creative field, which happens to be the core audience for anything Apple. Why is it then that these sites were produced with Flash? I'm not talking about a small banner here or a design element there, I'm talking about the entire site. So here I am, a person that is using my brand new iPad, trying to shop for a an accessory and come to a website that just shows a blank screen. There was no graceful degradation whereby a system that is Flash capable gets the Flash content and others get a degraded version. Not even a warning that you need to have Flash installed to view this site. This wasn't an edge case, I have found several sites like this and it's really a pity. Steve Jobs has made it abundantly clear that Apple has no intention to support Flash on these devices. The designs are good, but the implementation fell dreadfully short.

This is where I have to wonder; did anyone involved in the site's creation have any idea of their target audience? This embarrassment could have been prevented with a basic application of use cases. Use cases help developers understand what will be done on the site, the desired outcome and the expected platforms that will be used to access the site. In the process several use cases may be created depending upon complexity. This is the process I go through on each new project to ensure success. Without it, you're just aimlessly wandering down a path that may not render an appropriate solution.

With properly developed use cases in the hands of the developer, she would have made a sharp turn in the opposite direction of Flash and used a combination of CSS and JavaScript to attain the desired results. This is where the talent of the project manager or lead developer come in, to explain to the client that even though he may have wanted a Flash site, it isn't appropriate in this project and that this is the correct direction to take.

This particular use case is not a new one. About nine years ago my colleagues and I were tasked with building an educational web based game for a client. The target audience was an elementary school student that would visit the site using a school computer which may be locked down so tightly that Flash wouldn't be available. DHTML libraries were starting to become available to account for different target browsers and their quirks. These were the days that IE and Mozilla (the precursor to Firefox) were far from being standards based, but a library called DynAPI was available to to account for differences in browsers. This library is no longer supported, but now my go-to library has become jQuery. We ended up slicing up the graphics, assembling them in tables, and attaching various events to the appropriate images that the DHTML library would act upon and ultimately provide the desired effects.

While the final solutions may not provide best in total screen control, transitions may not be as smooth and fonts may not be exactly as the client and/or designer had wanted, the visitor to the site will receive a comparable user experience, regardless of the platform they are viewing it on. And isn't this what we want in the end?