Posts Tagged ‘Flash’

matt - Friday, June 25th, 2010

The Case For Flash & How HTML5 Will Rule The Web

Infoworld has 2 great articles that explain differing viewpoints on how Flash and HTML5 will advance the web.  Though this is being positioned as a “vs.” situation in the press, it’s most likely that Flash and HTML 5 will compliment each other in the future.  One of the articles has a good point that even with HTML5 reducing the need for plug-ins, for video in particular, we’re really just replacing plug-ins with codecs.  So real battle will probably be between H.264 and WebM.  The more things change, the more they remain the same….

HTML5 vs. FLASH: THE CASE FOR FLASH

HOW HTML5 WILL CHANGE THE WEB

blake - Thursday, March 18th, 2010

HTML5 vs. Flash

flashhtml5fight

There’s been a lot of talk lately about HTML5 and how it will completely change the landscape of the web.  Folks as high up on the technology food chain as Steve Jobs tout it as the ultimate replacement for Flash.  So, in an effort to be a good programmer, I spent some time learning HTML5 (specifically the canvas component) to compare capabilities.  I can emphatically say that HTML5 will not be a Flash killer, with the only possible exception being video, and here are the reasons why:

Just try to get a programmer to drop OOP

Flash is run through the ActionScript language, and  AS3, the version of ActionScript that’s been around for almost four years, is object oriented.  For those not familiar with OOP, it’s by far the most preferred method of coding for experienced software engineers, most of who consider non-OOP languages archaic (probably the nicest thing they would say).

On the other hand, JavaScript, which runs the HTML5 canvas component, is not a fully object oriented language, though in some ways it attempts to mimic OOP.  Creating a fully functional Rich Internet Application (other than basic information aggregators) in JavaScript is frustrating at best, and down right futile at worst.  Any way you slice it, moving from AS3 to JavaScript is a step down in capability, and no experienced programmer will rush to do it.

I have to manually support different browsers?

A Flash application will run on any operating system in any browser.  The only possible issue is the display of system fonts, which can easily be averted by embedding fonts in the application.  HTML5, though, brings with it all the same browser compatibility problems that currently plague web designers.  A HTML5 application playing sound or video will have to support every codec used by all major browsers.  So, instead of having one mp3 for every sound in Flash application, the developer will have to make a mp3, wav, and ogg for every sound that needs to be played and write code to test the browsers supported codecs.

The same goes for video.  Websites that want to support video playback will have to encode all their videos in both the h.264 and Ogg Theora codecs.  Imagine a site with a video repository the size of Hulu’s deciding to go through every single one of their thousands of h.264 videos and re-encoding them for Ogg, especially when their Flash video player works just fine for them already.  YouTube recently launched an HTML5 player, but decided not to support Ogg, so the only browsers it can be viewed in are Safari and Chrome.  Beyond the codec issue, the HTML5 video component actually does work very well, and I suspect that we’ll begin to see it used more often.

I’ve also noticed some screen redrawing issues that vary between browsers.  When redrawing large bitmaps on the canvas, the area would flicker sporadically, as if the browser couldn’t catch up to the redraw calls.  Once again, this is not an issue in Flash, since it takes care of redrawing the stage automatically.

Code obfuscation, anyone?

Code obfuscation is a process by which interpreted code, such as JavaScript, is modified to make it difficult to read without modifying the functionality of the application.  It’s used to keep code that has to be public from being stolen.  With JavaScript, you have no choice but to make the source code public and anyone with a moderate knowledge of web browsers can easily steal it, so obfuscation is a fairly common practice.

To help illustrate the current issues with code obfuscation and the canvas component, here’s a little Pong game I wrote in HTML5.  You’ll only be able to play it if you have a capable browser, such as Firefox, Chrome or Safari.

I attempted to use every online JavaScript obfuscation tool with the source code for that Pong game (only 280 lines long), but not one of them returned me code that worked.  I suspect that’s because they’re not able to handle HTML5 calls yet, or perhaps they don’t really work that well in the first place.  For the sake of argument, let’s assume that you, a developer, have successfully obfuscated your JavaScript code and have put it online.  An inventive hacker could find out which tool you used and reverse the process to get, at least, something close to the original source (encoded variable names might not be restored).  While Flash has it’s own obfuscation built in, and there are many decompilers for it, it’s a semi-interpreted language, so deconstructed applications reveal only snippets of the original source.

While I’m all for open source, site security dictates that some code has to be as close to impossible to hack as humanly possible (no code is 100% hack proof).  Most secure functions on websites are done on the server to keep hackers from reaching it through the browser, but with Rich Internet Applications that deal with secure information, there has to be an intermediary point where the application sends and receives sensitive data.  It’s much easier for a hacker to retrieve that procedure through JavaScript, obfuscated or not, than from a plugin.

Flash to the rescue

The idea behind HTML5 is a solid one.  The kind of functionality that Flash delivers is ultimately something that should move out of a plugin and in to the browser, but this isn’t an easy change to make.  The main roadblock is the core difference between web and application programming.  HTML has never been more than a document format, and through the last fifteen years of mass marketed internet, developers have tacked on external languages to give it greater functionality.  In the last few years, Flash has become the most used way to bring native application functionality to an HTML page, and it was able to do it because AS3 is a language of substantial depth, based on OOP principles.

Because of this, I think the best hope for HTML5 is for Adobe to add an “Export To HTML5″ feature to the Flash IDE and Flex SDK.  I suspect talk of it is already floating around their headquarters, because, despite what someone said, they are most definitely not lazy.

blake - Friday, February 12th, 2010

The Real Reason That iPad and iPhone Won’t Have Flash

ipadman

I used to hate Macs.  A work experience with a G3, that seemed to crash every ten minutes, turned me off to anything Apple for years.  Everything changed, though, when I got my first Intel based Mac in late 2008.  The user interface was flawless, the UNIX shell made it a cinch to do back-end tasks, and I never had to worry about the issues that plagued that old G3.  I haven’t bought a PC since (at least not without immediately wiping the hard drive with Linux) and I’m known around work as a hardcore Apple fanboy, but that might be changing really soon.

The vast majority of applications I write are for Flash (written in Flex).  I love the ease of Flash development and rarely have any issues with programs I write for it.  That’s why I’m particularly troubled with, what seems to be, Steve Jobs’ fevered desire to destroy the platform.  If you don’t know what I’m referring to, Jobs reportedly told a group of Apple employees that Adobe, the developers of Flash, are “lazy” and that the platform is “buggy.”

I call shenanigans.

There’s a common myth about Flash circulated by developers not familiar with the platform (also known as “my platform is better than your platform” developers).  They say that Flash causes most browser crashes when, in fact, it’s not Flash itself causing most of those crashes, but bad Flash coding by inexperienced developers.  To put that into perspective, I’ll pose a rhetorical question.  When an iPhone developer makes an app that crashes constantly or leaks so much memory that you have to restart the device, does anyone say that Apple should dump Objective C and Cocoa?

Since making the move to Flex, a while back, I haven’t gotten word of a single one of my applications ever causing a browser to crash.  This is after extensive use of these applications, not only by the public, but also by a quality assurance department as well.  Flash is a very stable platform when used correctly.

The iPad and Flash

Adobe has had a fully working version of Flash ready for all major mobile devices for a little while now.  Other mobile operating systems, like Android and Windows Mobile, are going to use it, so why not iPhone or iPad?  Steve Jobs, among others, would have you believe that it’s because the platform isn’t good enough for their devices, but that’s just a cheap cover-up.  The real reason is that it would take a massive chunk out of App Store profits.

If you own an iPhone or iPod Touch then you know that the majority of apps for those devices are – and I don’t say this lightly – complete crap.  The App Store is overrun with weekend projects by novice developers and rip-off products by companies re-skinning the same worthless app to get more 99-cent sales, and Apple is making a killing off of the suckers that buy them.  Don’t believe me?  Look at these screen caps from the App Store for latest releases in the Entertainment and Lifestyle categories, taken while I was writing this.

app_store

If Flash were allowed on these devices, almost all of those developers would opt to release their apps as “iPhone ready Flash,” raking in all the revenue from dozens of ads for enlargement pills and naked video chat, which they would surely cover the page in.  If Apple allowed Flash on iPad and iPhone, App Store profits would drop by a double-digit percentage practically overnight.

Why HTML5 won’t be a Flash killer

Because of this, Apple is publicly throwing their hat in the ring for HTML5, all while completely ignoring some of the glaring problems that come with it.  Mind you, HTML5 is a good advancement for the web, but it’s anything but a Flash killer, and here’s why:

1.  Video codecs aren’t free.  The reason that Flash works with all sorts of video codecs is because Adobe paid for them.  When that responsibility is moved to the browser, problems ensue, because not every browser supports all those codecs.  Mozilla has chosen Ogg, Apple is with h.264, since that’s what iTunes runs off of, and while Google is also currently with h.264, word is that they might be about to opt for a codec they just gained ownership of.  This means that not all HTML5 video players will work in all HTML5 capable browsers.  This is a huge headache for developers, since cross-browser is the name of the internet game.

2.  HTML5 can’t make the level of games that Flash can, or at least not with anything near the same ease of development.  Casual Flash gaming is a huge moneymaker, and no one is ready to drop it anytime soon.  Just for fun, ask just about any Flash game developer what he would think about dumping ActionScript to write a game in JavaScript and enjoy watching his head explode.

3.  Whatever HTML5 will do, Flash can already do it and then some.  As time goes on, and more functionality becomes available with HTML5, Adobe will, through their normal development cycle, give Flash more and more features that HTML5 won’t be able to compete with.  Two years from now, it might be that video players and simple rich internet applications are best done in HTML5, but, in order to do the latest things available, you’ll still need Flash.

4.  Flash has a dedicated user base.  99% of computers in the modernized world have Flash installed.  Safari and Chrome, which make up about 14% of total browser penetration, are the only browsers capable of running YouTube’s HTML5 video player.  Things might change for HTML5 penetration, but not soon.

The future of my Apple fanboy status

I’m struggling to remain an Apple fanboy, with their ridiculous practices regarding Flash and closed development.  The truth is, while I’m not happy with the direction their mobile division is going, I love OSX to death.  I guess, as a developer, I still admire the hard working people at Apple who, behind the scenes, actually do all the heavy lifting that results in great products.

On the other hand, Steve Jobs is starting to look less like an innovator to me and more like the delusional cult leader that so many Windows fanboys characterize him as – blindly saying that technologies that don’t conform to his wishes are buggy and that their developers are lazy.  I can’t help but think, at least for a while, that I won’t be drinking his special brand of Kool-Aid.

Oh, and he also reportedly trashed Google because they’re making competitive products.  When the Google Tablet mockup shows multitasking and multi-touch, the Chrome OS has open development, and the device will almost assuredly run Flash, it feels to me like nothing more than sour grapes.

Follow me on Twitter, @blakecallens

jack - Monday, December 21st, 2009

Being Pitched An Augmented Reality Execution? Here Are Some Questions To Ask

So, your agency is pitching you on an Augmented Reality (AR) execution. And as much as you’d love to move forward with something, the fact is you might not know that much about AR. And why should you? It’s rather “cutting edge”, especially in terms of its marketing implications, and you have a ton of other things to worry about.

As a marketing agency (Zugara) that also develops our own proprietary AR technologies (and seeing as how it’s the holiday season and all that jazz) we thought it might be nice to arm you with some important questions to ask your agency. This way, you hopefully don’t end up paying for an agency to simply have an AR execution that looks great on their reel, but never actually engages a consumer. Noted below, are a few questions/issues you should be cognizant of, and the reason they should be included in your thinking. HAPPY FESTIVUS!

The Question: Will this be built in Flash (if online)?

The Reason: One word: “Downloads”. We’ve harped on this before, proprietary technologies require downloads and a significant number of consumers drop out of a process when faced with one. So why do it? Flash’s install rate is nearly 100%. If you’re going to put your budget and time into AR, the least you can do is give your consumer the opportunity to enjoy it.  Below, you’ll see a tweet that was sent to me.  I track the term “augmented reality” on Twitter, and whenever someone tweets that term, I see it.  @woscholar tweeted about an unpleasant experience he was having with a Avatar cross-promotion that McDonalds is running.  I engaged him in a conversation, and here’s his feedback regarding the download that AR execution required:

tweet

The Question: Why aren’t we just creating this experience within the browser (i.e. Why isn’t this just a traditional web site?)?

The Reason: Is the idea you’re being pitched to just have a 3-D model pop out of a marker and essentially push your message to the consumer (be it via a key-ed out video or the like)? If the AR doesn’t truly add anything to the experience, why put the budget against it and limit your campaign’s potential reach (due to the need for a web cam)? Ask your team if you’re using this technology just to use it. Think about your goals. Think about your objectives. Think about your consumers. If AR can be a natural extension of the story you’re trying to tell, then perfect! If not, just keep it in your arsenal/thinking.

The Question: Will you walk me through the entire consumer experience?

The Reason: Taking the time to answer this question can expose fundamental flaws with the concept. Sometimes an idea can sound fantastic on the surface, but when you go step by step through the consumer experience you begin to realize something: no consumer would ever do everything it takes to participate (e.g. you may realize that the user would need to put their computer or web cam on the floor to get the necessary camera angle). Seeing as how you want consumers to “do stuff”, this can be a good way of vetting ideas.

The Question: Why do you think a consumer would do this?  What is their payoff?

The Reason: Obviously, the days of the consumer sitting there patiently listening to your entire message/ad are long gone. It’s the consumer’s world, and we’re just living in it. They need a compelling reason to interact with your engagement… to give you their time. One good litmus test is to put your “consumer hat on”. Odds are (unless you’re working for Nike, Apple, or a few others) most of your consumers “like” your brand, but aren’t passionately fanatical about it. So, think about a brand you “like” (not yours), and think about whether or not you would interact with it if they launched an execution similar to the one you’re contemplating. If the answer is “no”, then think about what it would take to make you participate. If you can’t find anything to make the offering compelling, perhaps this execution is not “the one”.

The Question: Why are you pitching me a mobile idea, versus an online idea?

The Reason: A mobile execution would be cool and cutting edge, granted. But for the near term, it’s limited in its reach (do more people have computers or iphones/blackberrys?), and functionality. Although not widely publicized, the fact is the hardware running on smartphones is not ready to deliver the consumer experience you’re expecting (I wrote more about this back in June), and the much beloved iPhone’s API still remains mostly closed to developers (which means you can’t have an iPhone read a marker like online unless it’s been jail-broken – which most consumers would never do). Not to mention, there’s apparently no rhyme or reason as to how Apple accepts/declines apps for the app store… so there’s the potential for your investment to never see the light of day.  To be clear, in our opinion mobile AR will be huge in the future, it’s just not there yet.

The Question: What’s the experience for the consumer that doesn’t have access to a webcam?

The Reason: There aren’t any publicly available, industry standard metrics on web cam penetration rates. This much is certain though, as of today, a significant number of your audience doesn’t have a webcam and you can’t ignore them because they will come to the site looking for an experience.

The Question: Are you sure this is even possible?

The Reason: Odds are, you’re being pitched by someone who’s not an expert in the technology. They’re creative, and smart, but most of the time their ideas just flat out aren’t doable (either in the near term or without a ton of R&D). Before you get your boss excited about the idea, it’s probably prudent to make sure that it’s technologically feasible.

So, what do you think? Agree? Disagree? Are there other questions that brand managers should be asking their agency? I’d love to hear your thoughts.

You can find me on twitter @jack_benoff

festivus-7113951

matt - Friday, December 4th, 2009

Web 2.0 Conference – GE’s Plug Into The Smartgrid Augmented Reality Case Study

About 2 weeks ago, I was on a panel at Web 2.0 on Augmented Reality with some of the thought leaders in the Augmented Reality space – John Havens, Robert Rice, Ori Inbar, Jack Mason and others.   Erik Manley and Michael Eisenreich from GE had a great presentation and case study on the GE Plug Into The Smart Grid Augmented Reality Campaign from earlier this year.  This was a great use of Flash and Papervision to create a very compelling Augmented Reality execution that helped usher AR into the mainstream.

I embedded the case study below as there are some great stats from the campaign (more than 1 million Augmented Reality users!)  Definitely worth checking out below:

GE’s Plug Into the Smartgrid Augmented Reality Case Study

Here’s the video demo of the campaign if you have not seen it before:

blake - Tuesday, December 1st, 2009

Why Flash is the Future of Augmented Reality (Including Mobile)

There’s been a lot of negative talk about Flash AR executions lately, and it’s deserved. Too many brands are using development houses that have no more understanding of the FLARToolkit than throwing a 3D model on a marker, let alone how to use it for successful product promotion. So, I completely understand why some of my peers, mainly those in the mobile AR realm, are rolling their eyes at the title of this post. Hopefully, I’ll make a good case for my claim, which is that Flash is the best breeding ground for new AR concepts that can then be brought to a wide array of other platforms.
_________________________________________________________________________________________

Mobile, Location based AR is the star of the moment. Many developers in the genre state that it’s what Augmented Reality is all about, but these GPS and compass based applications are only a small fraction of the types of engines being created and even already readily available. This has led to a rift in the AR developer community, causing the term, “True AR,” to be regularly used.

What is True AR? It’s the real time calculation of camera data being fed by the device to create an AR experience. Almost all web AR executions are True AR, although most of them right now are just True Gimmicky AR.

The limitations of GPS and compass units on mobile devices makes current mobile AR apps light on usability. The developer community has coined the melding of True AR with this genre to provide more accuracy, “Hyper-location AR.”

Unfortunately, there’s a problem with Hyper-location AR and any other True AR experience on mobile devices: processing constraints. It takes a whole lot of calculation to process camera data into a virtual construct, and while native applications on desktop computers are handling it well, mobile devices are still a little sketchy. This brings me to my first point:

Flash’s processing restrictions are a good thing for AR

Eye rolls again, I’m sure. Here’s the thing – if an algorithm runs well in Flash, you can be sure that it will run brilliantly on any mobile platform. Flash’s processing restrictions keep it running about the same, or just under, the iPhone, Android, and Symbian devices, when it comes to computation. An algorithm that allows me to track a hundred separate points in an image, per frame, might work out to 125 to 150 points on a mobile device (admittedly a guestimate). Meanwhile, an algorithm working in Java on Android might work a little slower in Objective C on the iPhone, or vice versa. When you start with Flash, you’re always moving up.

Flash is a very easy language to port

Yes, Flash is my favorite platform, so take this with a grain of salt. I didn’t get my start programming in ActionScript, though, and I’m well familiar with c++, Java, and Objective C, which run Symbian, Android, and the iPhone, respectively. Let me use c++ as an example, since it’s the primary language being used to create high-end AR engines.

If you take apart a large c++ library like bazAR, a feature recognition engine, it can be like reading Klingon. That’s because of how c++ variable naming has an effect on the processing of an application. In an engine like bazAR, that’s performing a huge amount of calculations, keeping your variable names as small as possible makes a huge difference in the final product. Problem is, it makes it a pain in the neck to figure out what’s going on when every step isn’t completely commented by the developer (99.9% of engineers barely comment at all).

If you’re a development house that’s created an AR engine in c++, but want it to work on a wide variety of devices, either you’re lucky enough that the creator is familiar with every single mobile platform, or you’re going to have to bring in an outside developer to port it. Having cryptic code, which is almost unavoidable in heavy c++ libraries, adds a good amount of man-hours to that work, which translates to more money spent than necessary.

Why more than necessary? Because Flash variable naming has no determination on processing. I could name a variable public var thisVariableIsReallyCoolAndIThinkYouWillAllLikeIt and it would take the same amount of processing as public var i. While a c++ engine would likely have a function with a dozen single letter variables, that require someone reviewing the code to decipher the calculations just to get a sense of what’s happening at all, a Flash one could have a descriptive name for each variable that makes the function easy to understand. Basically, Flash is the closest to pseudo-code a full-featured language gets. It can be the Rosetta Stone for your AR engines.

I know that some folks are thinking, “But you can just write a wrapper for c++,” but if you do that, you’re adding extra processing in an already processor intensive app. It only makes sense to port to the native language of the device.

Flash has an ease of development not offered by other languages

You might think I’m gushing on Flash again with this, but it’s the absolute truth. ActionScript takes the developer from idea to proof of concept faster than any other language. Many of the back end calculations that need multiple third party libraries for other platforms are built into Flash and are extremely simple to utilize. I’ve had an idea about a body recognition algorithm at 10am and had it running relatively smooth in Flash by noon, ready to show as a new proprietary library. Try that on a mobile platform.

Also, Flash has, arguably, the most vibrant developer community online. The barriers to entry are low – sometimes too low, as is demonstrated by gimmicky AR – but it’s simply the easiest language for a seasoned developer to learn. You can Google the answer to just about any specific Flash programming question imaginable.

Accessibility, Accessibility, Accessibility!

So you’ve created an experimental AR algorithm and you need people to test it for you, break it down, and help you squash any bugs or weaknesses. Let’s say you wrote it for Symbian. How many people in your office, let alone your QA department, have Symbian phones? Translation: potentially thousands of dollars of investment for something that’s experimental.

Now, say that you built it in Flash. Try to name someone at your office that doesn’t have a computer with Flash installed. Sure, you might have to pay for webcams, but they cost a whole lot less than smartphones. Plus it’s ridiculously easier to do a public beta test with Flash, where someone will just navigate to a site, rather than having to manage users downloading a regularly updated app to their phone. Once the kinks are worked out in a Flash build, port it to Symbian or any other device, where your test time and budget are a fraction of what they would have been if you went the other route. That and you have a working demo that doesn’t require a potential client to have a special device.

Full User Interaction

If using GPS and compass input is AR, and using camera data is True AR, then adding motion capture and body recognition to the mix is Really True AR. The algorithms that run body recognition in current AR will be the basis for the so called “Terminator Vision” that tech bloggers love to talk about lately. Nowhere is it easier to construct and test these algorithms for mobile use than in Flash.

Something as simple as drawing vector body outlines for results testing, or parsing bitmap data for motion recognition, could potentially take hours or days with any other platform, but is done in minutes in Flash. Why spend any more time than is necessary when experimenting with one of many hypotheses? I couldn’t tell you how many of my ideas went bust within an hour or two with ActionScript, when it would have taken me a whole day or more to reach the same conclusion in another language.

The most important thing is money

Less money spent, to be exact. Go the Flash route and you can have an AR algorithm ready to be ported to any platform without hassle, free of device specific features, guaranteed to run smoothly, at a fraction of the effort and cost of other methods.

Now, let the text based eye rolling begin in the comments section. :)

Follow me on Twitter @blakecallens

jack - Monday, November 2nd, 2009

Augmented Reality, The Buzzword Du Jour

(NOTE: The following post originally ran in Agency Spy as an OpEd on 10/30)

What’s the buzzword du jour?

It’s the buzzword of the day…

Mmmmmm that does sound good. I think I’ll have that.

So, as most of you are aware, the buzzword du jour is actually Facebook Apps Twitter “Augmented Reality” (AR). And this week, a Wall Street Journal article regarding Esquire Magazine’s use of AR in an upcoming issue was getting passed around. In essence, they are taking what Popular Science and GE did this past summer and attempting to turn it up a notch by integrating several interactive videos as well as an ad from Lexus.

I applaud Esquire for the effort, for getting their hands dirty. It’s no secret that the print industry (like the music and movie industries) is getting absolutely turned on its head thanks to the digital landscape and consumer media consumption habits. They have to try something to garner interest and maintain revenues. I don’t think that this is going to help out their January sales, but maybe December’s will see a bump. And to be honest, their execution and the subsequent WSJ article is for the most part par for the course if you follow the AR space. But there are two elements of this article that I felt compelled to weigh in on, here’s the first:

“It is a gimmick, but we’re an entertainment medium,” says editor-in-chief David Granger.

Now, this is a first. Someone had the stones to admit that their execution is gimmicky, let alone be proud of it. So kudos for that but let me say this: AR doesn’t have to be a gimmick. In fact, it shouldn’t be. Your executions should be providing real value to the people that read your magazines and buy your goods your consumers. Now, I’m not saying that the “value” provided can’t be entertainment in nature, but I am saying that it should provide value outside of what a person can already do in their browser. Otherwise, why put the barrier of needing a webcam between a person and your content/offering? All you’re really doing is giving people a more complicated user interface.

Of course it’s easy to sit here and rip on someone else’s work without providing any real value, so here’s an idea: what if Esquire’s “fashion spread” allowed people to overlay images of an article of clothing on themselves ( for example ties) so that they could match (or in my case, learn how to match) them with their existing wardrobe. Editorial content could provide tips, tricks and insights. Now, that might provide some real value to consumers looking to make a purchase (not to mention the brands that sell those articles of clothing) and would be an execution that could be updated and utilized all year long (that is, Esquire could sell the space to various retailers each and every season).

Now, on to the second item that I wanted to address:

“Mr. Nordstrom says that Lexus could do AR ads in other places but that consumers have to download a piece of software to make the technology work.”

People do not like downloads. It’s just another barrier between them and your content, and people will drop off. Now, I don’t want to get too techy, but if you are advising a client to do an online AR execution you should seriously consider building it in Flash (at the very least, you should have a compelling reason why Flash is not the proper solution). Flash 10 has a 93.5% penetration rate (Flash 9 is at 99.6%) in mature markets, and Flash development is relatively fast and cheap. When you throw on the consumer benefit of no downloads, it becomes a pretty compelling solution. Now, the counterargument may be that Flash does not allow for the sort of rich 3-D image modeling that a proprietary plug-in will allow for (I’d argue that it doesn’t matter how beautiful the image/asset is if people aren’t seeing it, but that’s just one man’s opinion). Well, that’s all about to change in 2010 when Flash 10.1 hits the streets.

So, what do you think (note to trolls: please keep the ripping of my grammar and spelling to a minimum)? What are some of your favorite AR executions? How do you wish the technology was being used? Would you be willing to download a proprietary plug-in to experience an AR execution you’ve never seen before?

If you want to take this conversation to twitter, you can find me at http://twitter.com/jack_benoff

Zugara - Wednesday, October 14th, 2009

What’s New in Mobile Marketing – 10/14/09

Zugara - Friday, August 14th, 2009

How To Fix The Macbook Pro, Webcam and Flash Issue When Viewing Augmented Reality

Having issues seeing the latest and greatest Augmented Reality works on your Macbook Pro?  Join the crowd. As we’ve been developing more and more Augmented Reality executions, we’ve been encountering this issue with Flash and webcams – specific to the Macbook Pro.  For some reason, the Macbook Pro webcam is not set to a default to work with Flash so we had to look around for a solution.  Here’s what worked for us:

  • Control Click the Flash Object and select Settings
  • Go to the Camera Tab and Use the drop down menu to select USB Video Class Video
  • Close the Settings window and everything should work ok.

That should do it.  If that doesn’t work for you, please reply in the comments or send us an email at ar@zugara.com.  Or better yet, email Apple and ask why they haven’t created a fix for this yet!

Zugara on Facebook