There’s been a lot of talk regarding the future of Adobe Flash thanks to the blockade generated by Apple on the iPad and iPhone. It’s been covered extensively by the news media and blogs, but I figured as a Flash developer/designer, I’d chime in.

To paint a picture of my stance, I will say that:

1. I hope open-source OGG format replaces Flash video. Flash has standardized a ubiquitous video format for the Web, and it’s wonderful evolution we can’t deny. Gone are the days of multiple encodings for Quicktime, Real Player, and Windows Media, and I doubt supervision excluding a for-profit company would have succeeded. That said, I think the Web has evolved, and the fact that HTML 5 has dropped OGG as the definitive format is a politically-driven mistake. We, as the creators of the Web, should be embracing an open video format.
2. I’m not an Adobe fanboy. Flash provides a format of expression unlike any other, and while I admit that Flash work is my bread-and-butter (and that I’m coincidentally wearing Adobe-branded apparel as I write this), I recognize Adobe is a company that answers to its shareholders. Frankly, their Open Screen Project and claims of Flash being an “open” platform register strictly as propaganda to me, and I felt the need to point out this stance because of the opinions I’ve encountered at some Adobe user groups.
3. I don’t believe HTML 5 is the Messiah. I support universal formats that ensure consistency between browsers. However, formats, while well-intentioned, don’t always reach the Web–they are ultimately dictated by the market. If that wasn’t the case, we’d all be discussing XHTML 2.0 instead of HTML 5 and be visiting .MOBI sites instead of using Webkit on our phones.
4. Flash isn’t going anywhere. Flash is used for more than just the Web–it’s great for standalone applications, and its games can’t be successfully emulated with HTML + JS. Furthermore, it allows for data without browser refreshing, and provides a more media-rich interactive experience. Regarding standards, see #3.
5. I want to see Flash Player on the iPad and the iPhone, but I believe this responsibility falls to Adobe.

I think something many in the Flash community fail to realize is that Flash Player doesn’t play well on mobile, and it’s not exclusive to Apple products. I know firsthand, as I considered purchasing a Nokia N900 as a result of Apple’s embargo. I checked out Flash Player 9.4 on the N900’s browser while stopping in at NYC’s Nokia Store, and the performance was nothing short of atrocious. YouTube videos were so choppy that they weren’t viewable, and simple Flash sites crashed the browser.

I should mention that the N900 is powered by the same ARM Cortex-A8 processor as the iPhone 3GS (the 3GS is underclocked to 600 Mhz). Sure, there are videos of Google’s Nexus One playing Flash Player 10.1, however, I wouldn’t be surprised if the Nexus One’s Snapdragon 1 GHz processor is concealing Flash Player’s inherent memory issues.

Reinforcement for this argument is Mozilla’s decision to drop Flash Player support for their mobile Firefox browser just prior to launch. I’m still amazed that this hasn’t garnered as much press as the iPad announcement.

This brings me back to the title of this topic–the Future of Adobe Flash.

Personally, I wonder if Adobe might have lost its way. Their community support is excellent, and I use their industry-standard tools every day, however, they’ve seemingly become obsessed with supporting a proprietary platform instead of focusing on building excellent tools, and their evangelists seem to point outward for blame rather than looking within. As I mentioned in #5, I want to see Flash Player arrive on all of Apple’s products, however, I think this falls upon Adobe improving the player’s performance. As for my predictions:

1. Flash Player goes truly open source and somehow gets included in the HTML 5 spec. Sadly, this is unlikely, as Adobe licenses proprietary video codecs for HE-AAC and h.264. More importantly, it’d likely affect Adobe’s bottom line.
2. Adobe publishes an API for Actionscript that supports gestures. Gestureworks is already providing this, and Adobe’s not far behind. Personally, I’m holding my breath for official Flash SWF support.
3. Adobe starts building applications that publish content for HTML 5 and mobile platforms.

Obviously, #1 and #2 are less predictions than #3, but I think it’d be refreshing for Adobe to begin exploring these new mobile outlets as opportunities to provide new software. Can you imagine a software that publishes iPhone, Blackberry, and MeeGo apps–without doing translations from Flash? Now that would truly be interesting . . .

I’m a little late to post this, but BarCamp Harrisburg 2 has been officially announced. It’ll be on Saturday, April 10, 2010 from 9am to 5pm at Harrisburg University. Attendance is free–just make sure to bring topics to discuss! I was hesitant to begin promoting this so far in advance, but there’s already been a decent amount of signups, plus we already have more sponsors at this point than last year (to be announced soon).

Hopefully, the weather will be better this time around (for those not in attendance, BarCampHarrisburg 1 was held in January during an ice storm). The venue has changed, too–Harrisburg University has a tremendous facility, and the wireless and projector hiccups from last year will won’t be an issue here. Frankly, it’s awesome that they’ve been so open and enthusiastic about hosting the event.

Also new is the Website and registration process. Gone is the confusing Wiki signup, as we’re now using Eventbrite (I’ll confess to cherry-picking some of the features of BarCampPhilly’s Website approach, as it’s one of the few examples of Websites hosted outside of barcamp.org).

A common question asked by potential attendees unfamiliar with the format is whether or not they will be forced to present. The answer is no. Personally, though, I hope we have so many attendees that it’d be impossible for everyone to present. Even if Especially if you’re not in the tech or education industry (but have interest in it or the social aspects of the Internet) I recommend you check BarCamp Harrisburg 2 out.

This past weekend I made it out to BarCamp Philly, and as you can see from the photo above, the turnout was 200-300 people–pretty good. Little did I know that WordCamp NYC was going on at the same time, but I think I made the right choice.

I’ve attended so many BarCamps now that I feel like an aficionado; you start to immediately recognize what works and what doesn’t at these events. Fortunately, Philly’s version of this unconference was well-sponsored and well-organized. They had a Website, pins, t-shirts, an online/mobile schedule, a photographer, and a great turnout. Here’s a hit list of what I liked and what I didn’t like:

Liked:

1. Open Source Cupcakes. ‘Nuff said.
2. Carl Leiby’s online schedule. I’m against developing iPhone-centric sites, but this certainly came in handy.
3. The pamphlets (above). It included a handy grid for you to write out what you wanted to attend. Definitely a nice touch.
4. The diversity of attendees. There were attendees from education, medical, and insurance sectors–not just Web developers, which made it refreshing for conversations.

Disliked:

1. The venue layout (Nothing against UArts whatsoever). Hosting a BarCamp on multiple floors of a building proved a bit disorienting–and wasn’t conducive to camper interaction out of sessions. Of course, free space is what it is.
2. The logo. Bring back the Liberty Bell, or at least make the logo Philly-centric!
3. No breaks between sessions. This was a scheduling boo-boo, but I think the organizers caught onto it. They also didn’t schedule time for a closing session, but that was promptly remedied.
4. Name tag holders. They’re a personal pet peeve, I suppose. They’re a one-time use item, yet I have some odd sense of guilt that comes over me when I think about throwing them away.

This could reflect my session choices, but it seemed as if all of the sessions I attended were hosted by people interested in discussing a topic, but not necessarily qualified in leading it (by their own admissions). Granted, there’s nothing wrong with this approach, but I prefer that happy balance of workshop and discussion.

Overall, it was pretty cool. I’m starting to get the sense that BarCamps are essentially those great discussions you had in college that you don’t get post-academia. After all, once you’re out, how often do you place yourself in a room with a group of diverse and intelligent strangers to discuss a common topic?

Hauck Interactive recently launched a new Website for Events, Etc., the catering company from the folks over at the Hershey Pantry. The new site features some of my photography–and had me running out to all of the really nice wedding venues in Hershey and Dauphin county. Check it out.

I figured I’d dedicate a post to this topic since I just wrapped up a rather painful learning experience with skinning Shopify (the Ruby on Rails-based shopping cart service) with a complete Flash frontend. Judging from the lack of documentation online, I’m willing to bet I’m one of the first crazy enough to take on such a challenge, and I’d hope to save some other poor developer some time.

Shopify tools

For starters, here’s a few of the tools Shopify provides for skinning:

• Shopify’s API, which allows you to communicate with the inventory, products, collections, and cart on Shopify.com
• Vision, a toolkit for creating a Shopify theme.

Working with Vision

If you're wondering how to access Shopify's API for your store--and your store only, check this link in your Shopify admin.

I  started with Vision, which is this handy application that you can run locally, modify Rails/HTML theme files, and then test in a browser. Once ready, you simply zip up the theme’s contents and upload it via your Shopify store’s browser-based admin. A nice setup, though I came across a few technicalities–

• As of this writing, Vision themes are limited a 40 MB size limit, and rightly so, since it’s a browser-based file upload. I happened to be working with a site with roughly 300 MB worth of photos, so I was forced to host the assets on a different site.
• Shopify’s admin allows you to individually edit theme files, but if you want to upload a replacement you have to first delete the existing file. This made it very time consuming, since SWF files can’t be edited in a text editor.
• Themes are broken down into three folders:
  1. assets – files associated with your theme. Think images, javascript, swf files, etc.
  2. layout – this contains the theme.liquid file, which is basically the wrapper in which all of the templates are loaded
  3. templates – this contains a variety of necessary pages for a shopping cart site, like a product page, cart page, etc.

  A few things to note here: Unfortunately, I learned that the assets folder can’t contain subfolders, which lead me to a rather messy site structure. Your Shopify site will require all of the default template files. Since I was essentially rebuilding these all in Flash, I embedded my main SWF in theme.liquid and HTML-commented the include calls in theme.liquid.

Getting ActionScript working with Shopify’s API

The key here is authentication, as described in Shopify’s API. The API spits out XML, which is easy enough to parse in ActionScript, however, since API calls look like this:

https://API_KEY:SOME_PASSWORD@some-shop.myshopify.com/admin/orders.xml

they shouldn’t be queried from within Flash directly, as this exposes the shop owner’s API Key and password. Instead, it’s safer to create a server-side script, open the XML, and then feed it to Flash.

Once I got past this, it was pretty straightforward, with one exception–I couldn’t find the cart contents in the API documentation. After doing some asking around, I discovered that the cart contents can be found at your-shop.myshopify.com/cart.js. Now, unlike the API, this list of products contained in the cart is not XML, but Javascript Object Notation (JSON). Sure, I could have taken the time to write a JSON parser for ActionScript 3, but thankfully the good people at Adobe have already written one. It’s in as3corelib, which is hosted on Google Code.

Security and crossdomain goodness

Anytime a SWF file attempts to access content from a URL other than the one it’s on it first checks for a crossdomain policy. This is basically an XML file named crossdomain.xml that is hosted on the root level of the server (You can catch the dry documentation on this here and here).

Fortunately, Shopify has crossdomain.xml files prepared, however, it’s still a bit tricky.

Since they don’t want anyone hacking their main site, there’s no policy file on *.shopify.com. Granted, your-shop.myshopify.com has a policy, but there’s no way to pull your theme files.

In the end, I explicitly referenced all of my SWF files from static.shopify.com and relied on the crossdomain policy file on your-shop.myshopify.com, which looks like this:

<cross-domain-policy>
<allow-access-from domain="*.shopify.com"/>
<allow-access-from domain="*.myshopify.com"/>
<allow-access-from domain="www.mydomain.com"/>
</cross-domain-policy>


So that’s it in a nutshell. If you’re out there using Flash as a complete skin for Shopify, drop a comment and let me know that I wasn’t alone!

I figure I’d post this since I reached out to the Twitterati for reinforcement. I wanted to avoid the cliché of a red label and a character with horns, despite this being TorchBearer’s hottest sauce. Apparently my Twitter friends agreed, and I was able to convince the TorchBearer crew to go with something else.

As for the sauce itself, I have a bottle in my office, but haven’t touched it. Even I have limits

Is your laptop screen going dim when attempting to install Mac OSX 10.6 Snow Leopard? I figured I’d just mention this for those who have yet to install it.

I recently purchased a family pack and I proceeded to install the new OS on my unibody Macbook Pro–no problem there. Then I proceeded to install it on my circa-2007 all-gray Macbook Pro-and noticed that the screen went to minimum brightness. Initially, I thought it fell asleep, but after restarting it, it kept going dim. I then tried plugging in different external monitors–with no luck (the monitors kept turning off).

Finally, I came across this post on Mac Forums where someone used a flashlight behind the screen to find their cursor and complete the process. Hopefully, the word’ll get out.

Judging by the the bump in Twitter followers and the number of phone calls I’ve received this past week, I probably don’t need to share this link, but I/Hauck Interactive was featured in this past week’s Central Penn Business Journal.

(Yup, a little late with the link. I’ve been a bit busy)

My company just relaunched HersheyPantry.com,  making the site the second of four targeted to launch this month (the first being Broadway Video Digital Media, which provided a nice HII mention here).

I was pretty eager to redo the Hershey Pantry’s site because they have one of the best breakfasts I’ve ever had. Fortunately, they were very receptive to my recommendation of adding pictures of food to their site, so I did a number of photo shoots to provide all of the photographs. What I learned: Don’t take pictures of food on an empty stomach.