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.

Flash Builder 4 and Flex 4 Released

It feels like a long road, but today we’re releasing the final versions of Flash Builder 4 and the Flex 4 SDK. If you were one of the attendees at Flash Camp Boston, you got the final versions on the DVD (but we had to call it a release candidate) so there’s no need to update. For the rest of you, make sure to grab the latest and greatest right now. If you’ve installed previous betas/prerelease versions, you will need to uninstall those before you install the new versions.

I’ve been a Flex developer for a long time, since version 1.5, and I genuinely think this is the most significant release in the history of Flex. We made some huge architectural changes in this version of the SDK. The new skinning model which separates the logic of a component from the look and feel is going to let you create some very complex and unique user interfaces. An improved states model along with a much more efficient transitions/effects engine mean that it will be easier to create multi-screen applications with meaningful rich transitions. And arguably the most important thing we did was optimize. The compiler is much faster which means you’ll be spending less time compiling and more time building.

But the biggest thing about this release in my mind is Flash Builder. This tool has come such a long way and Flash Builder 4 is a home run. The added productivity enhancements like ASDoc support and event handler generation make it so much nicer to program. Throw in things like better refactoring and built in unit testing and you’ve got a very powerful IDE on your hands. I’ve been using it for a while now, but when I step back and look at it, I’m very happy with what the team accomplished. Hopefully you also enjoy the new network monitor and the DCD features which make it easy to connect to data and start building RIAs. And with the new leadership in place, the future of Flash Builder is only going to get better.

I’ve got a bunch of articles up on the Developer Center for using Flash Builder 4 with PHP. If you’re a PHP developer interested in testing the new features, these should get you pointed in the right direction. We’ve also got recordings up of all the talks at Flash Camp Boston which cover a variety of Flex 4 and Flash Builder 4 features as well as some thoughts straight from developers who are going to be using Flex 4 and Flash Builder 4.

Congrats to the teams who made this happen. I hope you all enjoy the hard work that went into the release.

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, 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 diversion 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 affects 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’s 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.

Grant Skinner Speaking at Microsoft MIX

Grant says it best:

While my primary focus is (and remains) Flash, I am an interactive developer. I would be sorely remiss to ignore other technologies. Not only does knowledge of other technologies potentially open new project opportunities, but it lets me reinvest ideas and mental models from them back into my work with Flash. Working with C# has already sparked some new ideas for me (not to mention a few AS3 feature requests). Knowledge of alternative technologies also lets us suggest the best possible solutions for our customers or talk them out of a bad one.

That thought should be extended to all technologies, including HTML5. As an interactive developer you have to be familiar with the technologies around you. The best part is that it’s a great way to get ideas for what you want in Flash/AS3 as Grant is finding with C#.

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 re-use 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.

HTML and Flash Thoughts

Kevin Lynch blogged today in response to a number of issues that have cropped up recently and does a great job of laying out both Adobe’s vision for Flash and for web tools. That and a couple of other posts got me thinking a bit. The first is Jeffrey Zeldman’s post. He contrasts Flash with some of the benefits of standards. Most of the time I see “HTML5 is going to kill Flash!!” without any kind of rational conversation on why. Jeffrey does a better job than most. His intro paragraph is a perfect sample:

Lack of Flash in the iPad (and before that, in the iPhone) is a win for accessible, standards-based design. Not because Flash is bad, but because the increasing popularity of devices that don’t support Flash is going to force recalcitrant web developers to build the semantic HTML layer first. Additional layers of Flash UX can then be optionally added in, just as, in proper, accessible, standards-based development, JavaScript UX enhancements are added only after we verify that the site works without them.

My Current Problems with Flash

There are a couple of things I hate about Flash inside the browser. Both of them were covered very well by Richard Leggett in his Flash/HTML5 post. The first is browser integration. One of the things I think a lot of users find annoying about Flash is that it feels so alien in the browser. We have basically a single API, ExternalInterface, that developers can use to connect HTML and Flash. But it’s very awkward and it makes both the development experience and end user experience feel very different. Flash has become the “black box” of the browser. If you take a look at AIR, you see how great those two worlds can be. Flash and JavaScript can call each other’s APIs, Flash can access the DOM, and JavaScript can call Flash only when it needs to, for things like playing sound or performing graphical tricks. SVG and Canvas add a layer of complexity to that, but I don’t think that’s an insurmountable hurdle. In fact, I think those two technologies, when combined with Flash, would make a very interesting combination.

But that leads to the other problem. Flash is horrible when it comes to the semantic web. And this causes some other issues, like deep-linking or search engine optimization that we’ve worked on, but haven’t perfected yet. As Richard says, and Jeffery notes, the current solutions aren’t entirely bad. Flash works very well with a CMS like Drupal so that you can have the semantic web layer and a Flash layer. And largely it depends on your project. In some cases that semantic layer isn’t going to be as important. It’s also important for developers to use Flash inside HTML where appropriate. Another thing I’d like to see is making it easer to create Flex applications that don’t take up the whole page, but work within an HTML context. Think a bit about what I said above combined with some kind of Dreamweaver/Flash Builder integration so that the developer can unify the HTML and Flash experience at a tooling level.

Adobe Is a Web Tools Company

People seem to think that Adobe has eschewed HTML5 in favor of Flash. A lot of innovation goes into Flash. We have a number of features that our customers want and we’re able to add those to the runtime and create tooling around them because we can move quickly an innovate. HTML5 is obviously more consensus driven. As a result, some of the details that would be require to add tooling support haven’t been fully nailed down yet. But we’ve moved ahead to do what we can. Dreamweaver continues to have great HTML and JavaScript framework support. We’ve shown sneaks of BrowserLab that will help HTML/JS developers see how their site looks in various browsers. We’ve included the latest versions of WebKit in Adobe AIR so that HTML developers can take advantage of a lot of HTML5 features in a desktop context, and in ColdFusion we’ve got support for creating ExtJS 3.0 components with ColdFusion tags. We even sneaked a feature at MAX that used Flash and Illustrator to display animated vector content using the canvas tag. So Adobe is supporting HTML5 in a number of different ways already and experimenting with even more. When the spec is nailed down, you’re going to see a lot of Adobe tools that support it.

Flash Is Driven By Customers

It’s important to remember that Flash isn’t some isolated plug-in that we maliciously deployed on 98% of web browsers and that consistently hits 80% penetration for new versions in 6 months. Flash is driven by customers. Both developers and end users. Developers still want content that runs the same way across browsers (and now devices). They still want web content that provides innovation around things like video, sockets, animation, data push, web camera, 3D transformations, and works across multiple platforms and 98% of the people on the web. There are some developers who won’t ever use Flash, and that’s fine. There are others who want to do things that HTML5 just doesn’t have an option for now. Flash is there to fill that gap. Part of the reason we can innovate with Flash is because we control the source code. While we’ve worked hard to be more open, ultimately it’s our customers demand for innovation that drives us. And I wouldn’t want Flash to open up and lose that ability to innovate. It wouldn’t be fair to our customers.

I’d love to see Flash do a better job of integrating with the browser and the semantic web. And I hope HTML5 pushes us more in that direction. I disagree that the era of plug-ins is coming to a close because I think there will always be web developers who want to do a little bit more and have the same experience across devices and platforms. Adobe can move at that speed while still offering tools for web developers of all stripes because both HTML and Flash are baked into our DNA. I genuinely wish for a more open dialogue between standards organizations and the Flash community. Unfortunately it seems like a “my way or the highway” attitude when it comes to web standards. I can understand that to some degree, but I think the web would be a much better place of everyone took a deep breath and took another look at Flash’s deficiencies and it’s strengths. With that as a starting point, I think there could be some very valuable conversations about how Flash can do more to support standards while still catering to customers who want new features.

On Google, YouTube, HTML5, Adobe, and Flash

Last night Google blogged about how they were experimenting with offering some videos on YouTube that support the HTML5 video tag and the H.264 codec, and that work in Chrome and Safari. This is part of TestTube, where YouTube’s engineers test out different products without rolling them into the main YouTube experience. YouTube and Flash obviously have a deep relationship. It was Flash that helped YouTube become one of the most visited sites on the Internet, and YouTube has helped increase penetration of newer versions of Flash Player by rolling out features, like H.264 support, that required the newer Flash Player versions.

There is always an undercurrent questioning if Flash is “going away” when it comes to HTML5. But I think YouTube is actually the perfect example of Flash and HTML working together. The same day Google blogged about the TestTube project, YouTube also rolled out a new rental service for some of the Sundance Film Festival videos, which is powered by Flash. And I think that shows the relationship that Flash and services like YouTube have in helping drive the web forward.

Video on the web isn’t just about watching a clip any more. There are ways to monetize it, either with advertising or by adding ways to protect content that lets people watch something after they pay. There are accessibility issues that need to be addressed like closed-captioning support. What about being able to consume video on mobile devices that don’t support the HTML5 video tag? These are all areas that Flash has found solutions to, which has helped the growth of video on the web and provided a reference for the HTML5 groups to see what works. And while there may be some arguments over the use of the H.264 codec, having Flash add support for that codec meant that companies like Google could roll out a Flash version and an HTML5 version without having to re-encode video. Flash has made possible many of the features in HTML5 by showing how good the experience can be. And Flash will continue to innovate and provide solutions to challenges on the web before those solutions can be standardized. It will remain the best way to provide cutting-edge technology to 98% of people online.

Open standards are incredibly important to the future of the web. Adobe continues to work hard to contribute to that movement and balance that with the need for our customers and developers to be able to create next-generation content that runs the same way on every operating system and device. If Flash wasn’t providing value to people, it wouldn’t be on 98% of the world’s computers and we wouldn’t see penetration for new versions reach 80% within 6 months of release.

So congrats to YouTube on the HTML5 video work. This is good for HTML and I think there will be a lot of Adobe, Flash, and HTML5 collaboration moving forward. Flash has an important role to play by providing innovative ideas and solutions for an increasingly multi-screen and multi-platform world.

Gartner RIA MarketScope: A Rising Tide Lifts All Boats

Boats ImageThere’s always a lot of back and forth between the Flash crowd and the Silverlight crowd. And that’s fine, everyone needs an enemy and competition ends up driving everyone to have better features, better performance, and a better platform. But one of the things I’ve always thought was that Microsoft’s entry into the RIA space would end up being good for everyone. Microsoft has a lot of developers but there are also a lot of developers who don’t like and won’t use a Microsoft solution. Those people also need RIAs.

According to the Gartner MarketScope on RIAs it looks like Microsoft jumping into RIAs pushed adoption across the board in 2009. I don’t have the full report yet but here’s the quote from the blog post that stood out:

Now that Microsoft has validated “heavy RIA” in the eyes of many enterprises, interest in RIA technologies is increasing across the board. Frequent Gartner inquiries indicate that clients pit Ajax vs. Flash vs. Silverlight against each other in evaluations for new RIA projects. What does this mean for JavaFX and other technologies? Tough to say for sure, but my bet is that the “heavy RIA” arena comes down to a battle between Adobe and Microsoft, and that there is enough room in the market for both to be successful.

This isn’t supposed to be a happy-feelgood post. I want Adobe and our community to kick ass and continue to be the leaders in the RIA space. But I’m glad Microsoft is raising awareness; it helps when we can talk about why our platform is better for RIAs and not go back to what RIAs are :) .

I’m stoked about 2010. Especially if it’s a battle between Ajax, Flash, and Silverlight. We’re starting to get a big lead in mobile, AIR continues to do well as a desktop RIA solution, and we’re starting to monetize our own RIAs with services like Acrobat.com. There’s been a slight trend towards “native” which is being led by the iPhone, but don’t discount the persistent desire to create rich, desktop-like experiences with all of the flexibility and scope of the web. The web is still going to win and RIAs will be a big part of that.

Photo by Flickr user jal33

Good Interview with Kevin Lynch on Small Screen Content

Beet.tv has a good interview with Kevin Lynch in which Kevin talks about the shift in how content is created. The gist is that content creators will start creating for the small screen and scaling up from there. I think that plays with how we’ve been talking about contextual applications. The small screen is a very different beast to design for and it forces you to really think about your user interface. You just don’t have the real estate to make mistakes on the small screen. That’s going to be a key discipline and I think we’ll see UIs scale up from those small screens which hopefully improves the UI on the larger screens as well.