I Hate That We’ve Gone Native

I love the web. I love web development, I love web applications, and most importantly I loved where we were going with web applications. I was obviously a huge proponent of rich Internet applications and capturing a better user experience inside of the browser. Combine a great user experience with all of the good things about running in the browser (deployment, ubiquity, cross-platform, free publishing) and I thought that was a winning combination.

Then the App Store came along. Now everything is about standalone mobile applications. It feels like the web has taken a backseat as developers plunge head first into building native applications and users download them in droves. What bugs me the most is that I’m the same way. Most of the applications I use on my phone have perfectly good browser equivalents but I use the native app.

Dancing With Wolves

So what the hell happened? I think it comes down to two things. One, the app store provided a much better economic model for developers. One problem with the web was the downward pressure it put on the economics of content. Actual dollars were replaced with eyeballs and people started giving away the content and making money on advertising. (Think about how this affects Google, the ultimate web company; With revenue driven by advertising, they get a cut. With revenue driven by the App Store, Apple gets a cut.) With the App Store, developers can go back to charging directly for stuff they create instead of giving it away. It’s also insanely easy. They don’t have to worry about taking a credit card, setting up payments, or anything else that developers don’t want to worry about. They just have to build software, set a price, and the checks come in. That’s incredibly compelling. Especially if you’re doing development in your free time as a hobby. Now you can easily get paid for it without having to do any of the business tasks that might bog you down if you tried to do it on your own. That frictionless entry has changed the game for a lot of developers and created a huge supply of native mobile applications.

But that doesn’t explain the consumer demand for applications. I think that lies in user experience of applications. Prior to the explosion in mobile apps, we were getting close to a native-like user experience with RIAs in the browser. The components were better, the user interactions like drag-and-drop were appearing, and we were tackling problems like offline access directly in the HTML5 spec. Even the browsers were one-upping each other to be faster so we could get closer to native performance. The gap between a desktop experience and an in-browser experience was closing quickly.

Then quality mobile devices came along and changed everything. Instead of a mouse pointer we were dealing with fingers. Instead of worrying about offline access we had a ton of new functions on the phone including built-in GPS, accelerometer, camera, and a compass. The fastest and best (and in some cases only) way to take advantage of these new features was with native applications. Furthermore, the web experience was very much stuck in the old “pointer” mode. Mobile Safari on the iPhone made HUGE improvements to the mobile browsing experience, but nearly all of the websites were built for big screens and mouse pointers. Using the mobile browser on the iPhone (or any smartphone) is a lot of zooming and dragging. Even worse, some of the things we worked so hard on when it came to RIAs, like drag-and-drop, didn’t work the same way (or at all) and became more of an annoyance than a great feature.

So almost overnight all of the user interface paradigms the web had moved towards were rendered useless for this generation of mobile browsers. There were some initial attempts at fixing the issue, the best example is iUI by Joe Hewitt, but most people moved towards native apps. With better access to all of the new features, who could blame them?

The Light at the End of the Tunnel

So what does this mean for Flash developers? To be honest, I’ve been a little nervous. There is a huge drive to get Flash on mobile devices when the world seems to be crazy about apps. If you want to build apps with Flash, you can do so with AIR for Android (and eventually other platforms). But I don’t want apps. I want the web. Up to now, a lot of the interest/debate has focused on consuming basic content in Flash. People want Flash on their devices so they can watch video and play games. But we were making huge progress on in-browser RIAs with Flash. I want that momentum back in mobile form.

But what if we can revolutionize the in-browser mobile application experience the way Flash helped revolutionize RIAs on the PC? There is already an undercurrent of anti-native sentiment in the development community. Take a look at Sencha Touch, which is a fantastic looking mobile application framework designed specifically for i-devices and the mobile browser. And their first marketing campaign is even better, declaring the “end of native” at WWDC.

That’s exactly what the Flash community should be striving for. What’s so great about native? The performance? The user interface? Those are both things we can overcome with better technology and better design. Is it that it’s so easy to make money? Then the web is ripe for a better business model. The biggie is feature access. But here’s where Flash has always led the pack. We’ve had camera/microphone access forever and have always led the way in expanding the functionality the browser could take care of. If we can follow that trajectory on mobile then Flash developers are in a great position to make mobile browser apps a reality.

And that’s what I’m excited about. Screw native. I’m a web developer.

PhysicalFoursquare – A Flash Player 10.1 Demo App Using the Foursquare API

As you’ve seen, we’re getting close to having a version of Flash Player 10.1 that will be available to the broader public. And a lot of the evangelists have been creating some cool demos of how Flash Player 10.1 behaves on the Nexus One.

I wanted to do something slightly different and build more of a functional application.

I come from a Flex background and so I haven’t spent a lot of time creating ActionScript only projects. And while Flex performs pretty well on Flash Player 10.1, doing an AS3 only project gives it a better shot at running, especially as the application gets more complex. So I went with ActionScript only and created an application that uses the foursquare API as well as the Geonames database to find and let me check into physical features like mountains, streams, and lakes when I’m out hiking and want to still be able to check into foursquare.

Thoughts on Building for Mobile Flash

As you’ve seen, a lot of Flash content will just work. And because of the AIR for Android packager, a lot of people will just end up building applications and not worry about creating in-browser Flash apps for mobile devices. But I wanted to try it. A few thoughts:

One, the Flex mobile framework can’t come soon enough. I have so much more respect for the old-school Flashers because rolling everything by hand is a pain. And I had it easy because I was dealing with a fixed resolution since I was specifically targeting the Nexus One.

Two, while I didn’t do much in the way of performance tuning, that’s going to be important. These are pretty beefy devices and we’ve done some great optimizations, but for complex Flash content, tuning your code will be central to a good experience.

Three, as Mike Chambers showed, hover content works, but I found it kind of annoying. The way it’s currently set up, the hover event fires after the down event fires. So using SimpleButton the way I normally use it didn’t quite work because the effect was off. I ended up just making the hover state the same as the down state.

Lastly, I was surprised how much just worked. I pulled a LOT of third party content into this application. Keith Peter’s Minimalcomps, the foursquare AS3 API by Tim Walling, my own AS3 library for Geonames, the Google Maps API, TweenLite, Shannon Hicks’ OAuthAS3 library – and it all worked just fine. Part of what I wanted to test was how much I could throw at the device and I was pleasantly surprised by how well it all worked even on the beta bits of Flash Player 10.1. So when you target these devices, you’ll be able to use a very similar workflow, which I think is important.

To see the application in action, you can check out the video above or test the application in your browser here. You’ll need to have a browser like Firefox 3.6 that supports geolocation and if you check in you’ll be checking in this poor guy. All of the code is available on GitHub and you’re free to do with it what you will. Unfortunately my OAuth implementation was half-assed, so the foursquare checkin didn’t work, but it works in the browser.

Couple of Flash Player 10.1 Nexus One Videos

Last week I did a very quick, Flip Cam-quality video of Flash Player 10.1 running the March Madness on Demand site on a Nexus One. There is some stuttering when I switch from portrait to landscape, but other than that, it plays pretty well. It’s hard to capture with the Flip, but I was pleasantly surprised at how well it worked.

Also, Harish, one of the Adobe Evangelists in India, ported an AIR application he built to a browser app with Flex 4 and shows it running on the Nexus One. It’s pretty slick to see how well a Flex 4 app works on that little device.

The Flash Mobile Advantage

A post up about Jeff Smith from Smule and why he won’t ever target Android.

Smith is part of a small but vocal chorus of app developers who say they don’t want to move to Android, even though it is growing quickly. His complaints: He doesn’t like the way the store merchandises its wares, and he doesn’t want to have to create different apps for each handset Android supports.

To me, that helps show the value proposition of Flash on mobile devices. You’re going to have to create custom Flash mobile content for each device. It’s not going to be write once, run everywhere. But you’re not going to have to rewrite an app from scratch and you’ll be able to use the same technologies and tools across multiple platforms which means you can crank out applications faster and make sure they’re higher quality.

As developers get more sophisticated, just like agencies have their own frameworks to give them a head start on the apps they build, you’ll see frameworks that decrease the time to market of mobile applications for different sized screens and different functionality. But the key is being able to use the same tools, the same language, and the same platform so that you can easily tweak and write those applications for multiple platforms.

Windows Mobile 7 Series

Calling all Silverlight developers.

If you are a .NET developer today your skills and much of your code will move forward. If you are Silverlight or XNA developer today you’re gonna be really happy.

I am shit-hot excited about Windows Mobile 7 Series. I think it looks great, and I love the design elements from the latest Zune software (something I also really like). And I think what seems to be their developer strategy is awesome. Take expressive platforms like Silverlight and XNA and bake them right into the DNA of the phone. The result is going to be some really slick looking applications.

I also used to talk a bit about a divergence in the strategies for Flash and Silverlight. Obviously they’re still competitors, but if the Silverlight experience on WinMo 7 is application based, I think it does represent a big difference in how Silverlight and Flash are approaching the mobile space. I don’t think there’s a right or wrong, just different strategies based on the two companies strengths. But in the end, I have a lot of faith that the Silverlight designers and developers I know are going to help build an ecosystem around Windows Mobile 7 Series that will look next-gen.

Plus, with guys like Anand Iyer shifting focus to WinMo, it’s clear it’s a very important part of the strategy for Microsoft.

Platform Shifts

Cool blog post by Don Dodge on platform shifts and how the world of technology is evolving. It also kind of mixes with a guest post on TechCrunch about the fragmentation of mobile.

The more interesting question for Flash developers is how the platform shifts and the fragmentation of mobile devices affect the Flash Platform. I think that the TechCrunch article is wrong, we are starting to see a coalescing around Flash. The Open Screen Project has signed up every major mobile partner except for Apple including RIM, Nokia, and Palm. If you trust AdMob’s stats, that’s a pretty good swath of people across multiple regions. Now that said, we need to deliver and users don’t yet have Flash Player on their devices, but it’s close. Serge Jespers, my evangelist compatriot, makes a good point in his video about trying to find all of the Flash-enabled devices. We’re on the verge of a crap-ton of devices in the hands of actual users.

What’s unique about this approach is that these will be available over the air. I don’t think we’ve talked about specifics, but part of the Open Screen Project is that the devices have to allow over the air updating of the most recent runtimes. It’s far, far, far from a silver bullet in overcoming mobile fragmentation, but it’s getting momentum.

Mobile Flash Content

That leads into what’s driving runtime adoption: great Flash applications. Having played with Flash Player 10.1 on the Nexus One, I can tell you some things work great out of the box and that performance is quite good. But a lot of Flash content just wasn’t made for the small screen and it shows. Think of how much bigger a finger is than a mouse pointer and you’ll see the problems. I think the “hover” issues are completely overblown, but there is a big difference between Flash content in a mobile browser and Flash content in a web browser.

One of the implications of this platform shift is that the current web experience won’t translate 1:1. I think this is one area where the iPhone has been successful is by “shrinking” the web and making it touch-based without requiring any changes by the sites themselves. It feels like you have the whole web. But that’s an interim step and it has its limitations even on the iPhone. If you want to be on the cutting edge of this new shift as a Flash developer, you’re going to have to structure your applications in such a way that you can easily customize the user interface for multiple screen sizes.

My hope is that we’ll see a number of frameworks and tools that do just that, but I think we’re in that period of freedom where it’s going to take a bit of elbow grease to show everyone how it’s supposed to work.

AIR and Flash Player coming for Android and Mobile Devices

If you’ve been a member of the Adobe/Macromedia community you’ve heard a lot about Flash on mobile devices over the years. After seeing what’s coming, I think this is what you’ve been waiting for. We talked a bit about Flash Player 10.1 for mobile devices at MAX, and having played with a working version on the Nexus One, I think it’s going to be great for people that want to consume bits of Flash content here and there, especially games and video. But what we haven’t talked much about is AIR for mobile devices.

Cross-device Applications

AIR has been a big success on the desktop partly because being able to create an application with native hooks and having it run cross-platform is a big benefit to developers and to end-users who jump around different operating systems. But the mobile landscape is an even bigger minefield. Apple’s phone gets all of the attention, but you’ve got Android out there, RIM’s BlackBerry, Palm Pre, Windows 7, and others. If you come up with a great idea for an application, you have to write it for all of those platforms. Or watch as someone takes your idea and copies it on one of those platforms after you invest all of your time building it for a single platform. AIR for mobile is going to let you use the language and the tools you know to create applications across all of those mobile devices much more easily. We’re starting with AIR mobile for Android and BlackBerry and Kevin Hoyt has a demo video up that shows it in action on the Motorola Droid. And with AIR for mobile you’ll get access to multi-touch, accelerometer, GPS, creating your own gestures, screen orientation, and other device-specific APIs.

Introducing the Mobile RIA

One of the things that’s going to become very important for developers is creating content specifically for the small screen. Tools like Flash CS5 are going to make it very easy to reuse assets and workflow to create both applications and in-browser mobile Flash content. With AIR for mobile you can take the same application and run it on Android, compile it as an application for the iPhone, or deploy it on Mac, Windows, and Linux on the desktop. Depending on the device, you may want to make some small modifications, but you’ll be able to reuse your assets and a bulk of the code to quickly create cross-platform mobile applications with AIR mobile.

Because of the screen size and the very different specifications of each device, it’s going to be critical to customize content as much for a single device as possible and make sure you’re following best practices. There is a good article on creating mobile RIAs over on the Developer Center and Thibault Imbert has put together a great beta paper on optimizing mobile content for mobile devices.

Flash Platform Tools and Workflow

There is always a lot of talk about the future of Flash and which devices it’s on. But the ecosystem of Flash has gone way beyond an animation engine that’s limited to the web browser. No matter what you’re doing, the tools and workflow of the Flash Platform are going to give you the ability to deploy the most creative applications across the most used devices. Some of those applications will be mobile RIAs in the browser and some will be AIR mobile applications that take advantage of native APIs across mobile operating systems. For developers it really is one web, any device, and any kind of application. So get ready to go nuts and show every other developer how mobile applications are supposed to look.

Google’s FLASH10.1y New Phone: Nexus

Well the details are out on Google’s phone, the Nexus, and it sounds impressive:

The phone is 11.5 mm deep, slightly thinner than the iPhone 3GS at 12.3 mm. It is also slightly lighter than the iPhone 130 grams v. 135 grams)……..But most of your interaction with the phone will be through the gorgeous 3.7 inch 480 x 800 OLED capacitive touchscreen. This is the best mobile phone display on the market today, blowing away the iPhone’s 480 x 320 display………This phone is also powered by the Snapdragon 1 GHz core processor, which is more than able to handle the Nexus One’s 3D graphics, multiple applications running in the background and heavy browser use simultaneously.

From the software to the hardware to the UI it sounds like this is going to be a very good phone. But it gets better. Back at MAX we announced that Google was joining the Open Screen Project. And we’ve been working closely with Google since that time to make sure that Flash Player 10.1 works well with Android devices. And we’re also working with content creators on optimizing their Flash content for the smaller screens.

So as part of the Nexus announcement Adobe got our hands on one of the phones and we’ve been testing Flash Player 10.1 on it. You can see Adrian Ludwig demo an early version of it on the Nexus. We’ve also got a video of Adrian demoing Flash Player 10.1 on the Motorola Droid.

Flash Player 10.1 is still expected to be available in the first half of 2010 so it won’t be too long before you’ll be able to get your hands on the best RIA mobile experience out there.

Adobe and RIM Collaborating on Tool Support for BlackBerry Devices

At the developer conference in San Francisco today, RIM and Adobe announced a collaboration around creating content for BlackBerry devices and Adobe’s Creative Suite tools. This builds off of the momentum we started with RIM when they announced they were joining the Open Screen Project and dedicated to bringing Flash Player to BlackBerry. There are some good links on Techmeme that cover the announcement pretty well.

rim_adobe_announcement

Creating Content with Adobe Tools

Adobe is known for first class design and development tools and today’s announcement means that you’ll be able to use those tools to target RIM’s devices. There are going to be multiple points of integration. One of the critical pieces of creating mobile content is to make sure it is optimized for the smaller screens and often less bandwidth. In Creative Suite 5 we’re going to support optimized graphic and video content from Adobe Photoshop, Adobe After Effects, and Adobe Illustrator. We’re also supporting a seamless workflow between those design tools and BlackBerry’s developer tools including the BlackBerry Web Plug-in for Eclipse and the BlackBerry Java Plug-in for Eclipse.

More interestingly for developers, we’re going to be working closely with RIM to enable full support for BlackBerry devices in Creative Suite Design Central, Dreamweaver, and Fireworks. You’ll be able to use those three tools to test and create content for BlackBerry’s mobile browser as well as to create widgets directly on the BlackBerry device. Device Central is a fantastic way to test both HTML and Flash content for specific mobile devices. It lets you tweak battery settings, screen sizes, and other phone-specific functionality. Now we’ll have support for most of the BlackBerry phones so you never have to leave Creative Suite to see exactly how something will look on the phone.

Lastly, on the application front, Adobe is to be working on applications for BlackBerry that will let users take rich media and image content from the phone and quickly and easily bring it into tools like Photoshop Elements and Photoshop.com so it can be edited and modified.

BlackBerry Momentum

My colleague Mark Doherty has some great stats on what the BlackBerry market looks like and what this collaboration will mean for people who want to use their existing skills with Adobe’s tools to create mobile content for BlackBerry. Seeing the level of cooperation between Adobe and RIM is an exciting thing for designers and developers. Unlike some companies, I think RIM sees the value in partnerships, and with the breadth of Adobe tools it means they’re able to leverage our community for all kinds of different content- not just Flash.

Next year is going to be incredibly exciting for Adobe developers and designers. We’ve already talked a lot about Flash Player being available for smart phones next year, you’ll undoubtedly be hearing more about AIR, and hopefully we’ll continue to see deeper mobile integration across all of our tools just like you’re seeing with RIM here today. For more information you can check out the BlackBerry portal on Adobe’s site to get the scoop on the details and see some of the workflows in action.