Reaching new heights with the Oculus Rift

Whether you’re a hardcore gamer, or someone who has never touched a video game in their life, the reaction when putting on the Oculus Rift for the first time is invariably the same: “Whoah.” When you try to explain the experience to someone, you can point them to YouTube videos, describe the 3D effect of the headset and how it projects a separate view onto each eye, talk about how it’s like you’re “in the game…LITERALLY!” But ultimately it just ends with “Just put it on…you’ll see.”

Yesterday I took out my game demo of Solo: A Climbing Adventure to the Hub in Sarasota to show it off and get some reactions from people outside of my development bubble. Tony Marr of To Mars Games was kind enough to give me a tour of the space in return for ample time on the Oculus :)

IMG_1845 IMG_1848

It was great to see hear that the gameplay felt compelling, and equally useful to see what was difficult (such as searching for handholds before falling). Someone suggested natural gesture controls, which I am already exploring with the Leap Motion and Hydra, and I came away with some new ideas on UI in the Oculus, which is one of the challenges of the new VR immersive experience.

But most of all the reward of taking Solo out for a spin in the real world was just to see the enjoyment other people had playing the game. It was some early validation that an immersive game using rock climbing as its core gameplay mechanic is something worth pouring my time into.

One of the best aspects of developing your own projects from scratch is you get to work on every facet of development, from coding, to art design, to story development. When you get a little burnt out on one, you can switch gears and reenergize with something else. I’m excited about building on the skeleton of a storyline, where you are cast into the northern mountains of Afghanistan on a mysterious quest, aided by a grizzled veteran who serves as your mentor. I may finally put my faded anthropology degree to some use in building a rich story that will pull users in and make Solo not only about the novelty of climbing cliffs in immersive VR, but a full adventure game as well.

You can download an Oculus, or non-Oculus version of the current demo here. Please leave feedback as I am constantly thinking of how to improve the game. Solo is also now available on Oculus VR Share!

Oculus VR Share

 

 

Phonegap Android tips

I recently used Phonegap to produce my iPhone app, Boxing Coach, which I’ve been very happy with. I love phonegap and being able to avoid Obj-C for 90% of production is SO nice. Yes, I hear you out there…”Obj-C is actually not that bad…given a week of diligent study you could…blahblahblah” But I’d rather do my simple app logic in javascript and HTML5, especially if that means porting to Android with only a day or two of extra production. That’s the theory anyway.

The iPhone version of Boxing Coach, using the nice new plugins architecture of phonegap, went very well. I used iScroll to handle some scrolling mayhem, which was great. Although there’s still some issues with the onscreen keyboard messing up layout from time to time. I used the uicontrols to hook into the native iPhone tab bar functionality along the bottom, which with a couple tweaks worked well too. Local database storage worked great, audio played nicely, all in all a happy experience.

Anyway, on to Android. I’m going to condense notes here and maybe expand on them later via comments if folks are interested.

First I had some trouble setting up the Android project using the droidgap command via terminal. I’m on OS X, fyi. I checked my java, ant, android sdk all installed correctly. Had the system path stuff set up as well. Ended up being simple syntax stuff. Here’s what worked:

ruby ./droidgap “/users/max/documents/android” “MYAPPNAME” com.maxmediacorp.MYAPPNAME “/users/projects/phonegap/myapp/www” “/users/max/documents/MYAPPBUILD”

Ah, so now after following the other basic Android Getting Started instrux, I had a project in Eclipse to start tinkering with. Firs thing I had to do was replace the bottom uicontrols from iPhone build with basic html-based button images with onClick handlers. No problem, not sure why I just didn’t do that from the get go to make portability easier. Probably was just enticed by using “native” iPhone controls via phonegap :).

The next thing I noticed when testing on the device was that it autorotated, when I wanted it to stay locked into portrait orientation. This was easily fixed by going into the manifest and adding an “android:orientation” param inside the activity node of the XML, ala

android:screenOrientation=”portrait” android:configChanges=”orientation|keyboardHidden”

Nice, now no more ugly autorotation to landscape breaking up my layout. Orientation-aware apps are overrated anyway, right? While on the topic, there was a bunch of extraneous stuff inside the manifest left over by droidgap that I removed, unneeded permissions, a camera activity? I nuked them and app still works so hopefully no harm done.

Next annoyance was anytime you used the trackball on my Nexus One, the whole app view would scroll up alarmingly off screen. Not good. Touch events were handled nicely, via the e.preventDefault I presume within the main js code. But trackball had its own rules apparently and wasn’t getting caught by phonegap. After a bit of searching through Android docs, finally stumbled on the following fix, which can be added to your main app class (the one that extends DroidGap)

@Override public boolean onTrackballEvent(MotionEvent event) {
return true;
}

No more trackball mayhem! I love simple solutions.

That’s it for now. Hope those bits are helpful to folks. I’ll post more as I come across them. My next problem is how to start/stop/restart a thread in Android to handle folks leaving my app, coming back while saving its state, etc. Who said multithreading is a good thing?

FATC Mobile Workshop materials

Thanks everyone who came to the Flash and the City (FATC) pre-conference workshop for mobile and devices! Hope you picked up a few new ideas about developing with Flash for mobile devices. For those who would like to check out the source files and slides I used, here are a couple links:

PDF of slides

Source files for walkthrough

Hope to see everyone again next year at FATC, or sooner at another conference!

Ovi Store and GetJar Downloads: Three Week summary

OviOk, it’s been about three weeks since my Species Explorer mobile application passed Ovi QA and popped onto the Ovi Store, and about two weeks since I added it to the GetJar storefront as well. So a good time to sit back and see how the downloads look and start a bit of simple analysis on how effective they are in getting your mobile application out there. Or I should really say my Species Explorer application, because a different application may have completely different downloads than what mine has.

Before I start into the numbers, a couple things about the application. Species Explorer Mobile is an application designed to work with my Species Explorer online site and let users browse and post wildlife sightings using their mobile device. For the current version, this means a Nokia 5th edition touchscreen phone like the 5800 or N97. The application is a free download.

For both stores, I did very little cross-promotion as I wanted to see simply how many downloads could be generated by the store itself just by existing in its catalog. So no credits injected to put it in any “featured” area, or Google ad buys, etc. GetJar does offer tools for publishers to pay to promote their apps, Ovi does not as far as I  know, yet, but I’m sure will be coming in Ovi “2.0″.

For Ovi, the application was entered into the Social Networks area (It didn’t really fit neatly into other categories, and Species Explorer is essentially a social network for wildlife enthusiasts). For GetJar for reasons I have already forgotten (perhaps just to contrast with Ovi’s category) it ended up in the Travel->More Travel section.

Ovi Store

So enough preamble, let’s get to numbers. For Ovi Store, the first week’s download numbers were a pleasant surprise. They looked like this:

Day 1: 553
Day 2: 1425
Day 3: 1512
Day 4: 743
Day 5: 628
Day 6: 495
Day 7: 264

After that first week, the numbers dropped quickly to below 100 downloads per day, levelling off to be between 20-30 downloads per day on average. I assume the dropoff to be directly correlated to how quickly my app fell off the main “home” screen at the Ovi store. However, I may be wrong, as Ovi says that applications are sorted by a variety of factors, newness presumably being only one of them.

What struck me as much as the surprising (to me) number of initial downloads was the variety of countries downloading the application. To date, 137 countries have downloaded Species Explorer, with the top 10 being:

#1 United Kingdom 533
#2 Italy 448
#3 Germany 313
#4 Turkey 308
#5 Saudi Arabia 303
#6 France 294
#7 Spain 281
#8 India 249
#9 Indonesia 195
#10 Russian Federation 170

Considering my app is only in English, it was nice to see so many international downloads. And just reinforces to me that Ovi is definitely very powerful for giving your application a global reach.

All in all, I was more than happy with the results from getting Species Explorer onto the Ovi Store. Now I will be looking into ways in which to keep the application “fresh” and visible (the old “Top 25″ problem in the AppStore?) I expect Ovi will be pushing out ways for publishers to do that this year. For now, I presume getting good reviews for your app, and star ratings will help bump your app to the top of the list.

GetJar

I put up Species Explorer Mobile on GetJar a week after Ovi, so the stats are a bit sparser in more ways than one. For the two weeks it’s been there, the application has about 100 downloads. Although I am a bit suspicious of the stats as it seems it will say one number in a view, then show another when I click another view, ie going from month to month in the reports. So not sure if they have all their backend ducks in a row there.

In any case, no matter the view I pick, the total number of downloads comes to 100. A far cry from the whirlwind of activity I saw on Ovi. Which could be attributed to a variety of possible factors:

- no GetJar catalog preinstalled on handsets?
- app category less visible than the category chosen in Ovi Store?
- less of an international presence and/or smaller user base
- fewer supported handsets (5th edition touchscreen) in GetJar userbase

GetJar does offer various stats options for download/viewing, which again seemed inconsistent (eg show “no data” when there should be data). But they do tell some info, such as that a majority of users are to the 5800XM or N97 handsets. This jives with what the Ovi report showed as well, which was basically 60% 5800XM and 30% N97.

Moving forward, I’ll look into a few ways to try and boost more traffic to these storefront and/or position it more prominently. Also when the app becomes available to other platforms like Android, iPhone, etc I will compare experiences there as well.

The bottom line for now, Ovi seems to be a great opportunity to get significant downloads. GetJar is, at least for my app so far, less powerful. That said, GetJar is free and easy to get your app up onto its store, so no reason NOT to do it as well. So do both! Please share any comments and corrections to the above.

eSeminar 12/17 Open Screen Project: A Fundee Speaks

With the tongue-in-cheek title (which I realize most won’t take as tongue-in-cheek, and so just think I’m a weird guy) of “A Fundee Speaks”, I’ll be doing an eSeminar next Thursday, 12/17 at 12pm EST. Details of how to connect are available at Alessandro’s announcement page. I’ll try to cover some of the details of the application process, my specific experiences as a fundee, a brief overview of the components developed for OSP, and answer questions from seminar attendees who are considering applying to the OSP. I’m going to try and leave ample time for Q&A, so can try to answer specific questions from folks.

Hope to see you there (virtually, that is!) Oh, and did I mention that a software package will be given away worth up to $2100? There, I just did.

Max

Getting your KuneriLite Flash mobile app ready for Ovi Store

One of the most confusing aspects of getting a Flash-based Symbian app out there is navigating the process of getting your app signed. If you work with 3rd party tools like KuneriLite, it can be even more, uh, interesting. But if you like using Flash with services like GPS, upload/download, etc and find Nokia Platform Services aren’t cutting the mustard, KuneriLite can save the day. A fully-signed .sis is required by mobile storefronts such as Ovi, so this blog entry will run through the process of signing a Flash Lite app made using KuneriLite plugins. At the end, your sis will be ready for submission to Ovi, and you will be only slightly less sane than you are now.

I could just list a bunch of links to FAQs, forum discussions, pdfs, etc, but hey, that’s what makes this whole thing confusing in the first place! So I’ll just go through the steps I followed, with a few screenshots and comments along the way. Strap in and enjoy the ride! This is based on my experience getting my Species Explorer Mobile app signed and up to Ovi. Note that all this is based on a Mac OS environment, PC users adapt as needed :) Although actually you’ll need both Mac and PC environments to go through it all. But hey, real developers have three of each right, plus a Droid, iPhone, 3 N97′s etc.? Just kidding, sort of.

1. Get TC TrustCenter Certificate
Unless you’re self-signing, you need one of these to sign your app (in my case Express signing). Go to TC TrustCenter and get your certificate and publisher ID. You’ll have to pay $200, provide your business and contact details. You also will have to provide some kind of proof of business validity, eg articles of incorporation (gasp!) or some other legal doc. And you’ll have to fax it (gasp again!) over to the friendly folks (they are actually) in Hamburg, Germany to process. They have a rule about if your articles are older than a few years (which mine were) but if you’re registered with Dun & Bradstreet as a biz that’s also good enough for their needs. I was so my application went through.

After sending in your application (they won’t deduct your $200 until you’re approved, btw) and being approved, which can take a few days, you’ll get an email with a link to retrieve your certificate. Once you go to that link, click the “Install Certificate” button, the cert will download, and Keychain Access utility (again we’re on a Mac folks!) will launch and prompt you whether you’d like to add your cert to a keychain. I chose login keychain, not sure it matters.
keyinstall

2. Make .cer and .key files
While you’re still in Keychain Access, it’s time to export the .p12 key file you’ll need in order to generate the .cer and .key files you’ll need to plug into KuneriLite for our next step. So click on My Certificates in Keychain Access, find your brand spanky new TC Trustcenter Cert, expand it to see the key, right-click and choose Export…a picture is worth a thousand words so:
exportKey

Now, did I mention that although I said we’re doing this on a Mac, I presume you have a PC emulator or real PC available to handle a few little things? Well, if I didn’t mention that, sorry, but you do. So fire up that PC (or Parallels or what have you) and go grab a little tool called TC-ConvertP12 (don’t pc tools have such warm and fuzzy names?) and unzip it. Now copy your .p12 file from earlier into the TC-ConvertP12 directory. Open the command console, navigate to that directory, and type in the command to generate the .key and .cer files you need. Use the password you entered when you exported the .p12 file (you DID write that down right?).

tcconvert
Once you execute, you should get a nice success message:
keysaved
You should now see your .cer and .key files in that same directory, eg “myApp.cer”, “myApp.key”. Whew! Now on to KuneriLite!

3. Buy KuneriLite professional and plugins. (oh, you’ll need a PC/PC-emulator again, as KL is PC-only)
In order to use KuneriLite plugins in a signed application (that is, not self-signed), you’ll need to buy KuneriLite Professional. Some notes about why this is so are available here. But besides the general recommendation that users will always see a warning if it’s self-signed, if you use GPS plugin you need it signed, and Ovi won’t take self-signed applications. And if you’re targeting 5th edition phones, you WILL need to buy the latest KuneriLite (in case you’re like me and had the old KL that just was for 3rd edition phones) which as of this writing was 0.9.8. So…onward to the KuneriLite store. Pay your 250 euros, tell them what plugins you want to use, and provide your UIDs needed for those plugins. “Huh?” you say? Oh, yeah, you’ll need a bunch of UIDs assigned from Symbian to give the KuneriLite guys to apply to your unique set of plugins they will be sending you after you purchase KuneriLite Pro. There’s some info about this provided on the checkout page, but basically what you need to do is…

4. Get UIDs for KuneriLite plugins and application
Go over to SymbianSigned.com and login or register as a developer if you haven’t already. Once logged into your account, choose UIDs from the left hand menu. If you already have a bunch of UIDs you’ve requested previously, select as many as you need (info you should have gleaned from the Kuneri notes on the Kuneri store checkout page above), making sure they’re from the PROTECTED RANGE, and write them down, or copy and paste them into the KuneriLite checkout form “UIDs” field. You’ll also want need one more UID of course, again from protected range, for your application itself.

If you don’t have any UIDs yet, just click the “Request ” link in the left UID submenu, choose protected range, tell them how many you need, and within moments you’ll see a range of UIDs for your app-signing pleasure.
uids

5. Complete KuneriLite Pro purchase
After submitting your purchase form, with UIDs provided, to KuneriLite, you’ll get an email from them with a link to download your plugins and instructions on what to do with them. It amounts basically to making sure the plugins get their own special directory in your KL install directory, that this directory is referenced in the KL wizard when you compile your .sis package(s), and that the special ID you were assigned by KL is used properly in your actionscript when you make your calls to any KL plugins. In actionscript then, this would look something like “http://127.0.0.1:2001/dXXXX/” as the URL prefix to use. Note the port 2001 which is different than the port used in KL Basic.

6. Compile your .sis using KuneriLite Pro
Once your custom plugins have arrived and been placed in their own directory as described above, fire up KL, create a project, and select options for that project from the first project screen. For me it meant selecting 5th edition phones, and FL 2.x/3.x (my app wouldn’t work on 3rd edition phones as it was a touchscreen app). Select the plugins you’ll be using, then click forward through the next screen (if you have files to add, do so on that screen, otherwise just go to the “Create SIS” screen). Finally you’re ready to point to that .cer and .key file you made earlier! Go ahead and click on the browse to file button next to those fields and set the paths. Also make sure the “KL Path” field is pointing to the “rsc” directory within your custom plugin directory. And put the main UID for your app in the appropriate field as well. Make sure your custom app icon is assigned (an .svg graphic file 44x44px), version number set, title set, etc. So basically it’ll look something like this:
kuneri

Also fill in your Publisher ID in the “Vendor” field (see below for note about how to find that if you don’t know what this is). When all looks well, click the compile green arrow button, and if Kuneri is happy with everything you’ve told it, you’ll get a success message at the end. Within the project folder you’ll find a couple new .sis files: one with a “signed” tag and one with “unsigned”. The “signed” one is the one you will be needing to send off to Symbian to get Express signed in the next step (unsigned one is needed for Open Signed Online, btw, so hold on to that one too), so let’s get to it!

7. Submit application to Symbian Express Signing
There’s several options available for signing your app at Symbian. To go into them all here would make my already fragile head explode, so suffice it to say that Express signing is the most expedient and straightforward, so we’re going with that here. BEFORE moving ahead though, it’s worth testing out your app first using Open Signed Online which is comparable to full signing except it’s locked to an IMEI number, ie one specific phone.

Ok, your app tests well and ready for the real thing? Go back to your SymbianSigned.com account, and purchase an “Express Signed Content ID” for $20. One of these is needed for every signing submission. So click on that option on the left menu. If that option doesn’t exist, it probably means you don’t have a Publisher ID assigned yet. But if all is well this option will bring up a menu letting you select how many content id’s you’d like (apparently no discount for quantity!) and you will be directed through PayPal to complete your purchase.

Once you have at least one Content ID available in your Symbian Signed account, you can choose the Submissions option on the left menu, choose Express Signed, and you’ll be presented with the first page (oh yes, there’s more than one) of the submission form. Before you even get into filling out the form though, you’ll see at the top a field asking for a zip file, “File (only zip-archives are allowed)”. This is where you’ll be posting your zip archive of your submission package. What’s that? Well, we have to make it!

8. Make zip submission package
The zip archive submission package must consist of the following, most of which is created by KL when it compiles your app:

  • your signed sis (from KuneriLite)
  • release.txt (from KL, you can edit more if needed)
  • generated.pkg (from KL)
  • pdf “manual” describing your application (can be named anything you like)

The generated.pkg file is the one that KL created during the compiling step. If you forgot to add your Publisher ID in the “vendor” field when compiling, you can make that tweak by editing generated.pkg. Open it in your favorite text editor and find the following couple lines:

;Localised Vendor name
%{"Vendor"}

;Unique Vendor name
:"Vendor"

You’ll need to replace “Vendor” with whatever your Publisher ID is. Took me a while to realize this is simply the same as what’s listed as your “Distinguished Name” in your Symbian account settings. Now you’re almost ready to zip this up. Oh, what about that pdf? This can be pretty simple, even a one page pdf describing your app. I believe it’s potentially used by Symbian internally for reference, ie it does not get delivered in your final signed .sis (so don’t worry about users having to download some huge doc in addition to your app). So fire up Word, or whatever, and export a pdf to include as part of the submission package.

When you have all four items ready, zip it up and you’re ready to fill out the rest of the Express Signed submission form. Select your zip file when prompted in the form, and fill out the rest of the details on the contact page. When you click Step 2:Application Info, your zip will be uploaded and checked for validity. If it passes, you’ll see the next page of the form. Otherwise, you’ll get some error message telling you what’s wrong with your upload package.

The Application Info page of the form is pretty self-explanatory, fill out the appropriate fields, pick your target phone to be used for internal testing, license, category and name of app, etc. The next page, “Application test result”, is where it gets more interesting. You will want to go over KuneriLite’s page about how to answer some of the test criteria questions. The first page of test criteria should most likely be all pass, with the Kuneri stuff coming into play on the next set. You can jump back and forth between the form and the KL info page to answer appropriately. The one not listed on the KL page for some reason was use of the Camera plugin, which requires you to fill out Yes to the “UserEnvironment” section and provide an explanation, eg “uses camera with KuneriLite”. For some reason in my experience there are two boxes provided for your explanation, and only the second field seemed to be used (ie using the first field to fill in your description brings up a form error upon submitting) so Symbian web site bug?

Anyway, once you click “Finish” to submit the form, it will process your submission (bye bye Content ID credit!) and then show you a link to download your shiny new signed sis. You will also see a note that your submission may be “audited” at a later date, and if fails, the hounds of hell will be set upon you…or something. Your submission(s) will now be available under the My Applications area, so can be downloaded later. And if you do a future submission, you can use an existing application as a “template” for your new submission form. So enough about Symbian, let’s move on to Ovi!

9. Submit to Ovi Store
Well, before jumping into Ovi-land, it’s probably a good idea to do some more testing to make sure everything is as it should be. So test again on all your target devices, installing the Express-signed sis you just received. Also if you don’t have a basket of actual devices to test with, try making use of Nokia Remote Device Access Service (you need to be signed up as a Forum Nokia Developer). With Nokia RDA, you can pick and choose from the whole range of Nokia phones to test your app. It works as a java applet that connects to remote (literally, they’re sitting in a big room in Finland) devices, install your sis, and test as if it was sitting in your hand. Very useful in my experience.

Assuming all has gone well in your final tests, you’re ready to submit to the Ovi Store. Now before you get too excited, I should say right off the bat that I’m not going to give a detailed walkthrough of the Ovi process like I have with everything up to this point. The main reason is, it’s actually very well presented on the Ovi site. Once you are registered and logged in, there’s a checklist right there on the main publisher page detailing all nine things to check off before your submission is ready to be sent to Ovi QA. So to get started, register as an Ovi Publisher, or login if you are already signed up.

Going through the Ovi checklist includes some things you already should be familiar with, and otherwise are straightforward, like uploading app icons, picking devices you have tested your application on (and consequently will be tested with in order to pass Ovi QA), picking a price point (if any), countries to distribute to, contact and support info, etc. And most importantly, you have to upload your newly signed .sis, “lock” your distribution details and get the Ovi QA ball rolling.

Within some amount of time, several days on average, you’ll get a response from Ovi QA on whether your app has passed. If it does not, you’ll get a friendly message from Ovi via email and in your account page detailing why it did not pass and what needs fixing. So things like how it handles autorotation, memory, app exiting, etc will be looked at. But you’ve already tested for all that, right? ;)
If you’re application passes QA, then…well, let’s just save that for another blog entry. I have blisters on my fingers. But in the meantime, sit back and watch this relaxing video titled Ovi Store 101 which covers some basics. Also Bill Perry’s slide preso may be of interest.

Finally, I should mention that this isn’t the only way to go through this process. There are other tools for various steps in the process, and in fact if you don’t want to use KuneriLite, there’s SWFPack as well, an online solution to packaging your Flash swf into a signed sis. And that solution may be ideal especially if you don’t need the plugins. If other folks in the Flash Lite community have corrections or additions they think would help fill out this entry, feel free to comment.

Max on MAX 2009

Before too many days go by and I get sucked back into my client projects, thought I’d inject my own fond memories of this past week’s Adobe MAX conference into the blogosphere. First of all, I have to admit upfront that I missed almost all the sessions while there, except for the keynotes, due to the fact that I was playing the role of “booth babe” at my Open Screen Project funded Species Explorer booth (see figure 1).Max at MAX 2009

For those who aren’t familiar with the Open Screen Project (like the developer I met on one of the shuttle buses, who politely listened to me rattle on about OSP while thinking the whole time I was talking about the Adobe Open Source Media Framework) it’s a 10 million dollar fund set up by Nokia and Adobe to support companies looking to develop “multiscreen” (aka “contextual”) applications based on the Flash Platform. You can watch a session about it featuring David Blaine, where he cuts me in half and then puts me back together. Actually, he does a card trick. And I talk about Species Explorer. And Mark Doherty and Bill Perry describe the OSP fund.

Species Explorer and OSP Fund

My main reason for being at MAX, as I mentioned, was to talk about Species Explorer, and my experience with the OSP Fund to anyone and everyone who would listen. What is Species Explorer? In short, a web site for people to post wildlife sightings and share them with other users around the world. The OSP fund helped me develop a mobile app, a desktop browser app, and an app that runs in the Playstation 3 browser as well. All fun stuff (and here’s as good a place as any to say thanks to Scott Janousek and Hooken Mobile who led up the majority of the mobile app dev) As a small developer with an independent project that had no outside funding, the OSP Fund was a great opportunity to move development forward. Thanks to Manu, Mark and everyone else who thought Species Explorer was an interesting idea outside of the normal casual games and technology-focused apps, and gave it the big OSP stamp of approval. Now it’s up to me to move it forward and take it to the next level. For those wanting to watch the session (audio with PPT visuals) here it is:

Other MAX Developments
The big news out of MAX that is burning a bright flashy trail (pun intended) through blogs seems to be the Flash to iPhone announcement. To me, it’s a nice push in a good direction, but doesn’t mean much to me in any immediate way. CS5 is a bit away, there’s lots of hiccups with that solution that will take a while to work out before it’s ready for primetime, and in any case the kind of hooks I need into the device probably won’t be there for a much longer time. A more immediate solution may be services like Ansca.

Augmented reality was a big draw too at MAX, and one of the few sessions I was able to attend. Like most others, I walked out of the session thinking, “Cool! I can’t wait to download the FLARToolkit and start adding augmented reality to…everything!”. It was only when I arrived home and tried to explain how augmented reality could be added to my projects that my wife brought me back to reality with a few simple questions, like “uh, who exactly is going to use that feature?” and “Why do you need that?” Don’t get me wrong, augmented reality is SO going to happen in one of my projects, just not until I can figure out a practical need that makes it better than alternative UI’s that users don’t need a web cam and printed media to use. Still, too cool to ignore. But even that postal service example is probably not REALLY used by many people. I mean, there IS technology already that helps you figure out whether something will fit in a box…I like to call it a “tape measure.” Google it.

What I did find compelling was the Adobe Flash Platform Services, a set of new, uh, services from Adobe that lets you easily share your flash content across a grab bag of social networks, mobile networks, including ways to monetize your content through ads, and built-in analytics. And that’s just the “Distribution” leg of the services, there’s cool collaboration and social network hooks (coming) as well. While there are some sharing widgets/services out there that serve a similar need, I don’t think I’ve seen anyone do it in such a robust way as Adobe is doing here, and especially one focused on integrating seamlessly with Flash.

Flash Mobile Community

Inspired by Dale’s thoughtful blog post on the sort of “where are we now?” (the “we” being those Flash Lite developers who have soldiered on year to year since the glory days of Flash Lite 1.1) I thought I’d try and add my own point of view as well.

This is a bit tricky, without sounding like a bitter old man complaining “why you young cuss, I remember when we didn’t even HAVE functions!” to these upstart developers with Flash 10.1 on their brain coming into mobile. But damn it, I DO remember when we didn’t even have functions. :) What we did have was a commitment to Flash, and a big interest in mobile, and an understanding that big things were coming for mobile and we wanted to be part of it. As a US developer, it never really came, mainly because not enough people had the phones with Flash on them, and if they did (hello Verizon and BREW?) there was no easy path to get your content on the carrier/phone. So most of us (not all, but most) of us Flash Lite devotees made some cool stuff that nobody ever saw, let alone bought.

MAX 2009 and FP10.1 may be a tipping point, where this all starts to change, time will tell. But as I have concluded each year in the Flash mobile space, progress IS being made. Hasn’t been as fast as I’d have liked, and there’s been significant deadends and missteps, but it HAS progressed. And if any time is worth looking at Flash and mobile, it’s now. With Google predicting huge market share for Android, Palm Pre entering the game, there’s reason to get excited. And of course there’s already big opportunities for folks targeting Nokia-friendly markets.

Like Dale I’m curious of how the “old guard” will interface with the “new guard” coming into mobile Flash now. I’m guessing we old guard won’t be obsolete any time soon. We’re a wily bunch, and I’m sure will adapt with the times. But that’s the young optimist in me now, not the bitter old man.

Advancing mobile storytelling DevNet article

fig04.jpg
There’s a new article up on Adobe’s DevNet area which I contributed to, “Advancing mobile storytelling with Adobe’s distributable player,” describing some of my experiences developing the Adobe MAX conference mobile guide for Adobe and Untravel Media last fall. For those looking for an in-depth tutorial with code and walkthrough, please don’t hate me – this article stays up on the surface more and takes a more “narrative” approach. :)

Michael Epstein contributed several sections focused on Untravel‘s work in mobile storytelling as well, with some thoughts on how the latest version of Flash Lite provides new ways to achieve their goals and “develop a global channel of location-specific travel stories.”

Flash Lite Analytics Stats

The Open Screen Project site has a an interesting doc with Flash Lite analytics stats looking forward through 2012. While the upward curves of global adoption is nice to see (and by now are used to seeing in these reports if you’ve been hanging around Flash Lite for a while) an eyebrow raiser for me was the very little year to year change in US in the chart: Flash-Enabled Handset Shipments by Region going through 2012. Would be nice to see not all the growth in APAC…

I’m hoping for a breakout year in FL, with the distributable player (despite Ovi announcement of non-support, doh!) and aggregator partnerships. Will be tough though. Dare I say it’s do or die time this year? Being a diehard Flash Lite optimist, I’ll bet on do vs die…