The words ‘photos’ and ‘vacation’ go together much better than ‘managing’ and ‘vacation’. But with today’s devices, we’ve come to accept there’s a little work to having so much technology at our finger tips. My family and I just returned from an amazing trip to Disney World in Orlando. Part of our efforts to refresh and truly escape from work was to avoid bringing laptops. Yet, with just our camera, an iPad and the hotel’s wifi, we were able to upload photos each night and easily share them with family. Here’s how:

The Photo Service
This is the website used to organize, share, view and store your photos. We use Facebook a lot, my wife especially. However, the photo sharing process for vacation photos is tricky. If you post photos while you’re away, you are essentially amplifying to the world that you aren’t home. Also, we’ve seen quality be an issue with Facebook, and we wanted our photos backed up in full resolution in case something happened to our camera or iPad while traveling. Before our trip, I took a cue from my dad and looked at Google’s Picasa (now called Web Albums). With it’s tie-in to Google+, I set up an album and shared it with just my family “circle”. This not only meant that just accounts in my family could view the photos, it also enabled notifications letting them know when photos had been uploaded. Google gives you 1GB free storage, so I upgraded to 200GB for just $50/year.

The iPad and Camera
I brought along an iPad 2 with the Camera Connection Kit (CCK), which allows you to connect either an SD card or the camera itself (via USB) to the iPad. Upon connection, the iPad recognizes photos (actually photos and video in the DCIM folder on the SD Card) and lets you import them into the iPad. One draw back (and a fairly common issue) is that our camera (a Sony NEX 5) stores video in a separate folder. Without a laptop, we had no way to move videos into a place where the iPad can see them. Once imported though, the photos can be left on the SD card or deleted. Just seeing the photos on the iPad in the standard viewer is a treat — sort of reliving those moments in 1024×768, swipe-able glory each night reinforces the fun times you had during the day.

The iPad App
Once Picasa was all setup, I needed to bridge the experience to my iPad. There are several apps that extend Picasa, and based on reviews and price, I chose Web Albums ($2.99) by Pixite. The Web Albums app has you login to Picasa and pulls down thumbnails of all our albums. You can view the photos, manage them within albums and define who the photos get shared with. You can import photos from your iPad (either from the camera roll or via the iPad’s camera). As you upload photos, you choose an album and you can even add a caption. One very important feature is the ability to upload the photos in their full resolution. This means the photos are backed up in a way that you can print, crop or edit them in the future.

The nightly routine
Having free wifi in the hotel was unexpected. I knew to expect in-room internet, but the wifi was excellent. It was very reliable and only slow on the upload speeds. Each night, after we settled in, I would import all photos on to the iPad. [I took 700 photos overall, and uploaded 100 of them.] I would go through all the photos, select the best ones and upload them to our Disney album on Picasa. Since I had plenty of SD cards, there was no need to remove photos off of them — but that certainly was an option.

Extras
I talked with my dad when we got back from our trip. He thanked me for sharing the photos with him and was thrilled to follow along each day. To begin enjoying the photos at home, I added the Picasa album to our litl webbook Media Wall and we were able to view an instant slide show. Overall, it was great to have everything woven together, knowing after each day that our memories were safely backed up and shared with the right group of people. With a little planning ahead, you should be able to enjoy and capture your vacation with less technology in hand.

This talk expresses my love and intrigue of APIs, demonstrating where I’ve found platforms and APIs in real life, music and things like wiffleball. I have a lot of fun with this one. At one point during this talk, I walk across the stage (or room) and throw various wiffleball pitches at my laptop, with the webcam on screen showing the sharp angles of the ball. This is to demonstrate how my arm is like an API, accepting the arm.throw() call with parameters like grip, angle and speed. I also define a subset of APIs I maintain with my wife and a bonus API-ification of the Delorean time machine.

Of over 40+ presentations I’ve given, this is has become one of my favorites. I’ve given this talk at GeekyByNature (NYC, 3.31.2011) and at NSWG (Newburyport, 9.29.11).

Diving a little deeper, I use examples like the traffic light as ways humans are universally controlled. I also show the asynch event response structure through the way our brain and stomach communicate on whether we are hungry or full. It may seem ‘out there’, but folks in the audience seem to get it very well.

The best part about this talk is the extended Q&A and discussion it leads to at the end. I encourage feedback and questions here, as comments, or to me on Twitter: @chuckstar.

The following are videos that I feature in this talk:

Back in 2005 when the “mashup” craze was really taking off, we were getting reports at Yahoo! about how many developers were using our Maps API. The report was broken down into technologies, web sites, and how many API calls were made from each. Sites like programmableweb.com were busy cataloging platforms and counting how many web sites and developers mashed them up (known today as integrating/extending APIs). Up until recently, many thought successful evangelism meant attracting as many developers to your platform community as possible. The more apps, the more API calls, and the more developers were using your service – extending your brand – calling attention to your service – bringing folks into your domain, and so on.

In some cases, you could see where companies were looking more at their developer totals than the number of quality apps being built on their platform. Not to say this wasn’t a valuable practice. For companies considering developers as customers, the sole purpose of the platform may have been attracting users directly rather than indirectly — through the apps developers built.

But for many companies, this approach ultimately failed. It costs big money to (properly) evangelize to developers, appear at worthwhile conferences, support SDKs in multiple development languages, and adequately power a good performing platform to deliver your service to countless apps and developers.

In advising many companies, I’ve referred to this approach of going out and marketing/evangelizing your platform to any developer as the “butterfly net” strategy. That is, you are going out with a big net to catch as many developers, no matter their ability, specialty or value, and hoping they’ll sign up, download your SDK and use your platform.

Eventually, of potentially thousands of developers, only a few valuable apps emerge. And while the service platform may provide for a nice weekend challenge, the platform may be no match for something out there that can better provide a developer with visibility and even a somewhat easy-to-achieve revenue stream.

There’s been a major shift in the last few years. Developers have become much more savvy in how they spend their time adopting new platforms and respective platform technologies (languages, frameworks, etc). The biggest and most obvious catalyst for this change is the success of device-based platforms like iOS and Android. While structurally different than more prolific service-based platforms (SDKs extending enhancing apps like geo-location, virtual currency, communication, etc), device-based platforms take even more time for a developer to adopt, in principal, and offer a proven incentive to developers — direct sale and monetization of an app. And so, service platforms not only have to be more discoverable to a developer, but they have to present a value proposition that competes with other platforms in a way that almost compliments them.

Many platforms, particularly the abundant and smaller service-based ones, can grow much more valuably now by moving away from the butterfly-net strategy, and align themselves more with traditional business development approach. This can be achieved in a more direct and even cost-effective approach. Instead of showing up with a booth at a conference and trying to ‘recruit’ developers point-blank, platform companies should seek out developers who may have already built apps that will benefit from their SDK. I find it’s easier to answer the question “how can I build this into my app?” over “how can I build an app around this platform?”. The other benefit is knowing the developer is already familiar with — and maybe even a master of — the coding language your platform supports. This, too, saves incredible time in supporting adoption.

I’m not suggesting you abandon the old-fashioned conference appearance. Platforms stories of technology and success still need to be told in front of interested developers. Again, don’t always try and push the platform to a new breed of developers. Try targeting audiences that may be already familiar with your platform, or even developers you’ve already presented to before. And after the presentation, webinar or meeting, listen a little more to those really interested in your service. Schedule time to walk them through docs and examples. See them through the integration of your service and you’ll see an app launched that brings more value to you platform than takes away from it.

It’s been 2 years since I wrote a native iPhone app and successfully launched it to the App store. I have been working with native Android off and on since July of 2010. Learning (really playing) with these respective platform technologies has been challenging and fun. In researching some new platform strategies for litl, I needed to start checking out some ‘write once’ technologies. I started looking at Corona and AIR especially. Ultimately, my familiarity and access to AIR led me to dive into reusing my Flash chops.. for now. The results, so far, have been staggeringly easy and exciting.

This demo app is pretty simple, using Touch events, some Flex Spark effects for animation and sound playback. The example is less than 100 lines of code. The devices you see are the iPad2 and the yet-to-be-released Samsung 10.1 Tab distributed at GoogleIO.

Overall, the performance on both devices is impressive. I’ve noticed a few more bugs on the Android side, mostly resulting in quirky touch handling and disappearing sprites. Also, the sound takes a little longer to load on the Android tablet. Aside from these issues, it’s been great showing these results to colleagues. I’m hoping to build out the demo app into an actual game. Also, I’d love to get my hands on some other devices (the Playbook and Nook Color) to test this process out more.

Here is an account of the steps I took to complete this experiment, along with approx times. Note the quickness getting this on my Android tablet vs the lengthy process of setting up my MBP to deploy to the iPad2:

Packaging apps for Android (from FlashBuilder):
http://www.adobe.com/devnet/air/articles/packaging-air-apps-android.html

Packaging apps for iOS (from FlashBuilder):
http://www.adobe.com/devnet/air/articles/packaging-air-apps-ios.html

The provisioning and certificate steps from Apple’s iOS dev center:
http://developer.apple.com/devcenter/ios/ [account required]

AS3 Touch Event handling:
http://help.adobe.com/en_US/as3/dev/WS1ca064e08d7aa93023c59dfc1257b16a3d6-7ffe.html

Later this month I’m presenting at Geeky By Nature. Just to give you an idea of the contextual brain power, the schedule includes Brendan Hall, Joshua Davis, Andre Michelle, Sir Keith Peters, Grant Skinner, Jared Tarbell, Lisa Larson-Kelley, Joe Ebert, Hillman Curtis, Gmunk, Robert Hodgin, Paula Scher, Alan Klement, Jer Throp, Rich Shupe, Joel Gethin Lews and Joshua Hirsch. Ever heard of Perlin Noise? The inventor of that, Ken Perlin, is also presenting.

Inspired by the collection of speakers and name of the conference, I’ve been piecing together a brand new presentation called “APIs For Life, Music And Wiffleball“. The gist of my talk is to get you thinking about APIs we use everyday OUTSIDE of computers, coding and software. If you just said “huh?”, then great! I’ve worked on 3 major coding platforms over the past 7 years — not to mention working with staple languages and technologies. I believe that a great API, the pure unlocking of functionality in a device, application or service, comes from understanding how we need to work with it.

So in this exploration, I’ve examined many things and recognized more natural and organic APIs in music, within ourselves, and in our interaction with each other. Things like:

How does your brain know you’ve had enough to eat? Your stomach has an API, and your brain polls it frequently to see if it’s full. However, there are performance factors like the speed at which you eat, the appealing flavor of the food, and the time you have to complete your meal that affect this ‘polling’. And even when your stomach is actually full, your brain may resist reporting that information to you. Stomach.addEventListener(“FOOD_EATEN”, checkIfFull);

How about looking at yourself as a husband or wife, and considering the ‘commands’ you use between you and your spouse/partner? If I were to generate documentation on myself as an object to my wife, it might look like: Chuck.helpWithDishes(); Chuck.putKidsToBed(); Chuck.haveASafeFlight()… you get the idea.

There are also APIs when looking at things like art and music. Like coding, we don’t simply follow instructions. Instead, by learning how instruments work, we creatively command the instrument to do things in our own way. So when I play the piano, I am saying: Piano.playChord(“C”, “E”, “G”); Piano.addEventListener(“SUSTAIN_PEDDLE_HELD”, holdNotes);

So now that you hopefully understand the method(s) to my approach here, I’d like to welcome your ideas! In the comments below, tell me what APIs you recognize in every day things that you interact with outside of code, computers and software. If I include your suggestion, I’ll be sure to give you credit. I look forward to sharing my presentation after I give it. Certainly, if you can make it to NYC later this month (March 31 – April 1), amazingly tickets to this event are still available: http://www.geekybynature.com/tickets/

In this video, I review Adobe’s AIR for TV Developer Kit and discuss where it could have great potential for developers getting content and apps on TVs. Also demoed is a 3D Flash game Kevin Suttle and I originally created for litl’s accelerometer-driven set top box prototype. The ported version of the game relies on AIR for TV’s simplified d-pad control.

Watch the video on Vimeo.

Since CES, I’ve been following the TV App space very closely. I launched a new blog back in January called TheZSpace.com which allows me to cover the various TV developer platforms as they emerge. ["The Z Space" refers to the depth of interaction between the user and the TV.] Even with litl no longer launching the TV set top box, I’ve remained very interested in how Google TV and the major TV brands (Samsung, Panasonic, LG, etc) are building their own SDKs to attract developers and apps. As I mention in the video, AIR for TV may have excellent potential in this space as the individual TV brands represent a very fragmented opportunity to developers — much more so than mobile or tablets.

Also mentioned in the video is my agenda for presentations on the topic. I’ll be presenting at Rocky Mountain Adobe User Group tonight. Then, in June, I’ll be presenting at the exciting Flash And The City.

If this topic interests you and you’re excited about developer opportunities on TV, check out our blog at http://thezspace.com and follow us @thezspace.

I doubt there’s a developer out there who hasn’t been tempted by the mighty powerful marketing forces of device makers calling for apps on their HOT, NEW, COMING SOON device! I should know. As Chief Channel Evangelist for Litl, it was my job for much of 2010 to encourage developers to build apps for a set top box device that has yet to be released. Most devices launch, and when they do, their success can carry with them the talents of the developers and apps that follow.

To a developer, the chance to BE THE FIRST to build an app for an upcoming device and platform could represent the opportunity to have your app get major visibility upon a product’s launch. However, it’s also risky to get involved with a device too early and may or may not be the best use of your time. Due to complexities of the device’s platform, be it varied technologies, add-on SDKs (see below) and other limitations, it’s likely the app you write for one device will need to be heavily ported or fully re-coded if you ever want to deploy for other devices on different platforms.

To help in your assessment of “app for device” opportunities, I have put together a checklist of things to consider before you commit to building an app for a device.

1. What’s the potential market reach?

Apple has critical mass and promotes Apps alongside their products

If you’re expecting to make money selling the app, the device’s distribution is key. You should know from the company that makes the device as much as possible about how many they expect to sell and when exactly the device will reach a critical mass. Also, if you expect the device to be super successful, you’ll need to account for a lot of competition among other apps.

If the company making the device has other, successful products out, chances are they’ll be a success. If this is their first product in the space, it is a bit riskier but the reward for being an early adopter in the space could be huge.

2. Will working with the device’s platform technology add to your skillset?

Good developers love to code, even as a hobby. Even after they’ve closed out their work email, they’re still tinkering with other ‘side’ projects, hungry to learn the next big thing and keep sharpening their skills.

Picking up a device platform could be a great and fun way to cut your teeth on a new technology. If you’ve never coded for devices before, it can really be an enjoyable experience. Also, if you’ve been stuck coding the same language for a while, building an app for a device can lead to new technologies and broaden your horizons a bit.

3. Will building an app for the device be good for your career or business?

If you work at a company, and they are servicing clients interested in a certain target device, then having a deployed app under your belt could be very valuable. Just the same, if you’re a contractor, and have or sense demand from your clients to deploy apps for a device, getting an app out would be great.

In this climate it’s not hard to identify opportunities like these. This might be the best excuse to dive into a platform and not look back. Going into work or sharing with clients an app of yours freshly listed in the device’s respective store/marketplace can be a big highlight for you! So if you’re going to play with a device on nights and weekends, consider one that has great potential for your career and business.

4. Are you over-committing your app to the device platform?

As mentioned above, it’s likely that the app you’ll build may only work on a single device (or with other devices from the same company or platform). If you’re going through the trouble of learning the device’s technology and building an entire app, especially from scratch, consider the effort of having to re-write it for other devices. Many devices share baseline technologies and languages. However, a lot of new ones require add-on SDKs. This means that in addition to adopting a specific language/technology, you’ll need to download and maintain the SDK specific to the device. This can really lock you in and make your app a slave to the platform.

Check to see if the platform has a history of “breaking API”, which requires developers to fix their apps with major API version releases. If it’s a new platform or device, see how frequently they’ve versioned their platform and tools. It might be a sign their going to be trouble.

If you’re using a proxy technology, a method of deploying an app in something other than the device’s native platform/language, make sure that it gives you access to the device features you want to build your app for. Also, check that the company building the proxy technology is keeping up with the overall versioning of the platform.

5. How valuable are you and your app to the platform?

In some cases, your app (and more specifically, having YOU deploy the app) may be more valuable to the device maker than you realize. Dig deeper and find out what incentives the platform support or evangelism teams are offering to encourage you to build for their platform. They may have a fund setup, or more likely, some big marketing dollars to grant you in the name of ‘developer acquisition’. Make no mistake, you’re participation and ability to deploy a quality app is very valuable to them. See what you can get from them (money, free software, and especially, a free device) before you submit your app.

6. Get your hands on the device first or get a first-hand demo or review.

Touching the highly coveted and hyped Blackberry Playbook at CES

More important than the sample code and support you’ll get as a developer, you must know the device you’re coding for is of quality. It must be something people are going to want or need. In most cases, it will help if you also want and like the product. Getting a hands-on demo of the product is very important, especially if it’s not been released yet. This has turned me off of more products than not. It really helps if you believe in the product, and getting to play with the device can boost your interest and confidence in it.

It’s really hard to build a quality app for a product that you don’t have. When possible, you should have the device handy to test with. Platform SDK emulators/simulators are helpful, but with so many different interaction points, ranging from touch response to accelerometer, being able to use your app right on the device can make it so much better. Hopefully, if you’re committed to building an app on a new platform, you’ve managed to get a device for free in the process!

—

I’m not going to list out any devices or platforms in this post that you should jump on or avoid. For now, I’d appreciate your feedback, via comments below, on what factors you look at when assessing a device platform’s potential and deciding whether or not you should build the next great app for it! Most devices coming out are great. Usually, if the company has put marketing money behind promoting it, then it’s likely to be huge! Why not be a part of it?!

We’re all a couple of weeks into 2011. Time to get serious about planning for this year. First, I really enjoyed 2010. It was equally exciting and stable for me and my family. We didn’t move across the country — something we’ve done twice in the past 5 years. However, we did have a baby — also something we’ve done twice in the past 5 years. I didn’t change jobs or roles — something I’ve done 4 times in the past 5 years. And compared with the 13 presentations I did in 2009, doing just 8 last year was a nice change of pace.

I’ve been doing a bit more technical business development at litl, which requires me to be more flexible for travel. Doing about 1 developer presentation/event every 2 months should be a nice pace. You’ll notice in the topics I’m set to give so far, I won’t be speaking about anything litl-specific as we’ve yet to determine the focus of our developer program this year. More on that in a future post…

So, for 2011, I already have 3 exciting speaking opportunities lined up:

1. RMAUG – February 23, Denver, CO – http://rmaug.com

I’ll be speaking to the Rocky Mountain Adobe User Group about “Flash apps on TV“. While I’ve been doing much less Flash coding of late, the opportunity for Flash in the TV space is of great interest to me.

Session Description:
Many are calling the TV screen the next frontier for app development. However, with your user 10ft away from the screen, there are many different factors including controllers, performance and platforms to consider.

Chuck Freedman, chief channel evangelist from litl, will review all the brands, technologies and opportunities for getting an app on TV. He’ll discuss where the Flash platform, as a plug-in, part of other SDKs and through AIR for TV, may have a promising place in this new space. Whether you’re interested in porting your app to the bigger screen, or creating a new experience, this will be an informative presentation for you. On TV, apps present new challenges to the developer. Assume nothing is universal and prepare to enter the biggest display space yet!

Check out Chuck’s new blog http://www.thezspace.com for the latest news and platform announcements in the new TV app space!

2. GeekyByNature – March 31, NYC, NY – http://www.geekybynature.com – Get Tickets

I am creating a new presentation called “APIs for life, music and wiffleball“. This will be a completely new session from me, and not specific to developing in any language or for any device. It’s going to be total fun and inspiration.

Session Description:
During a decade of coding & architecting software, service and device platform APIs, I’ve often observed the way people and things around me actually interface with each other. While some things come with instructions, many things in life have APIs which force us to learn technique in our own ways. In this new presentation, through images, code and video, I will evaluate common APIs that enable us to create, interact with people and master the use of various instruments, products and equipment. It will be fun and insightful. My goal is to provide you with a new awareness on how we work and communicate as platforms, and maybe how we can create other platforms more effectively.

3. FlashAndTheCity – June 9, NYC, NY – http://www.flashandthecity.com – Get Tickets

Big TBD here, but I know I’m going and will be doing something at this excellent event. I’m working with the organizer, Elad Elrom, on putting together an excellent panel. I might do a session on TV App development and design as well. Get Tickets Now

Hope to see you at one of these exciting events or on the road somewhere this coming year.

Also, while I’m not planning to attend or speak at these events, I suggest you go if you have the means:
FITC Toronto, 360Flex, D2W, and EyeOFestival

The first and only time I’ve been to the great Consumer Electronics Show in Las Vegas was 1996. My dad brought me during his remarkable streak (he went to them about 20 years in a row). 1996 was an incredible year in the consumer electronics space. At that show, the following were unveiled for the first time. I remember it like yesterday:

1. Plasma TV – Sony had a limited-access display behind a curtain where they showed about 3 models of varying sizes of plasma TVs. I had never seen a TV so thin.
2. MiniDV – I remember JVC had this tiny (by 90s standards) video camera which took a small digital cassette tape. It was an amazing standard, and I got to play with a few.
3. DVD – I still have a demo DVD disc from the Toshiba booth where we watched a presentation on how the new Digital Versatile (not yet Video) disc would change the way we moved data from computer to TV.
4. StarTac – Motorola had a museum exhibit-style booth where you had to line up to see their tiny (by 90s standards) pocket-sized cell phone.

So now, 14 years later, I will finally return. Litl is sending me to check out what will surely be no shortage of exciting platforms on display by every single major TV maker. I’m most interested to see how each company positions its platform — what apps will they show — what content partners will be showcased — how have they integrated new interfaces into their TV — are they doing widgets (a la Yahoo!’s Connected TV) or full screen, immersive apps — what opportunities are there for developers.. and more. [I'm exploring a new way to communicate my findings, so stay tuned.]

Anyway, if you’re going to CES, let me know and we’ll get together in Vegas. See you, and the future of the connected home, there!

My badge from Winter CES 1996

While investigating page turning options for potential projects, I came across these impressive examples. One uses Flash and the other is done with HTML5.

Flash, based on work by Didier Brun:
  http://www.bytearray.org/?p=77
  http://www.didierbrun.com/foxaweb/demos/as3/pageflip/PageFlip.swf << actual demo
  http://ma.tthi.eu/blog/2009/05/07/pageflip-with-shadows/
  http://ma.tthi.eu/dev/pageflip/ << enhanced demo with shadows

HTML-5, based on work by Rick Barraza:
  http://jpageflipper.codeplex.com/
  http://dl.dropbox.com/u/7235888/index.html << actual demo
  http://bit.ly/1k2Pne

Are there other examples you’ve posted that I can look at?