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 will hopefully improve the UI on the larger screens as well.

HTML5 Can’t Exist Without the Flash Platform

Let me start by saying I’m not anti-HTML5. I think it’s great. I think open standards are core to the DNA of the web and that’s part of the reason I’ve been encouraged that Adobe is moving more in that direction with AMF, RTMP, and some of our underlying protocols. But I also don’t think that means there is no room for companies like Adobe and Microsoft that want to see the web be better. I don’t think it’s an issue of corporate greed or vendor lock-in, but I understand the economics of how those end up being profitable. On the Adobe side I think it’s just that we have a lot of services and tools that we want to provide and we need a platform we can innovate quickly on. When the winds of technology shift we want to be able to make sure our customers can stay ahead. Video? RIAs? Real-time collaboration? Enterprise data management? All things our customers needed that we could build into the platform and make available to them. With the way open standards work it’s just not feasible to push those innovations through. So we’ve been very careful with the Flash Player. That’s how we provide our customers value. But it goes beyond features and into another problem with the web: a consistent experience. From browser to browser you’re going to get wildly different implementations of a “standard”. With Flash Player you can deploy your content and know it will run the same way for everyone that has Flash regardless of browser or operating system. There was an example today that made me chuckle and write this post. It’s not the best example; blurs and sparkly trails are not necessarily ideal uses of Flash, but in this context it was important. A group working on the NORAD Santa Tracker wanted to capture a specific experience; it added value to the overall presentation, and it was worth taking the time to create. Here’s the email:

Hey all-

My 20% at Google is the NORAD Santa Tracker, which gazillions of adults and kiddies use each year to track the progress of Santa across the world.

Last year, I used our Flash API to create the tracker map, primarily so that I could make a glittery comet trail of Santa’s past 7 stops. I tried it in JS with resized animated GIFs, and then decided that Flash would be much less painful – and was right. The code drew a line on a Sprite, blurred the line, then added some little sparkle movies and animated them.

You can see a screenshot with some trail here: http://www.wired.com/images_blogs/photos/uncategorized/2008/12/24/santa_nrad_edited.jpg

This year, I have ported the map to our JS v3 API, because we are doing aversion that utilizes the Earth plug-in (3d flying Santa!), and I wanted to make sure there was a version that didn’t require a plug-in. But, I really miss the glittery comet trail.

I wanted to get your advice on the best way to do this in JavaScript, given the following (flexible) requirements:
- Works in FF3, Chrome/Safari, IE 7+.
- Doesn’t require images (bandwidth is an issue).
- Doesn’t require a plugin

I’ve contemplated canvas, but not sure if that supports foreground blurring,and don’t know if it would translate to VML with excanvas. It doesn’t seem very SVG-y. I could try animated GIFs again, but they don’t animate the same across browsers. I could also try window.setTimeout with some PNGs, but that will slow down the browser, require images, and won’t achieve the same blurred line effect.

Do any of you have a better idea? (Help prove to me and the kiddies that Open Web can make magic happen! :)

Thanks!

- PamElf (<- my elf code name)

Not an off the wall request by any means. It’s a pretty basic task and using open standards in this case is a great way to go. Especially considering that she’d like mobile support for this (later email) and HTML is still the best way to target every level of device. What surprised me were the responses:

From: Jeff Schiller

My two cents:

SVG Web does support the blur filter so you could get this working cross browser if you force the flash renderer.

If you just forced the flash renderer for IE, that doesn’t solve the problem of Chrome/Safari who have not turned on their SVG Filter support.

SVG Web is a cool project to support SVG, but a requirement is that you have to use Flash. So even when you try to use open standards, you still have to fall back to Flash in some cases.

From: Dion Almaer

A hack would be to have a separate <canvas> that draws the blur w/ an opacity and z it? :)

Seems like a decent solution, but requires some hacks. This is fine for a 20% project, but when you’re trying to be productive, are hacky solutions the best way to go?

From: Alex Russell

How ’bouts IE 7+ with GCF? That’d let you try things like <canvas> more directly.

A perfectly fine way to do it, but GCF is the Google Chrome Frame plug-in, which would mean another plugin and as Pamela says the message after that, it’s not ideal at all from an end-user case.

Now I understand that the major roadblock here is the IE 7 requirement. If it wasn’t for that you wouldn’t need the Flash fallback for SVG Web and you wouldn’t need to use something like the Chrome Frame plug-in to make it work. But that’s kind of the point of open standards. Before you can really take advantage of a technology you need to get a consensus from everyone. All of the browser vendors have different agendas and different priorities. Right now Microsoft is the hold-out, but what happens if something comes along and threatens another browser vendor’s goals? Then they’ll be the hold out. That’s part of the price you pay for standards; you have to get everyone on the same page before you can move forward.

In the end, that’s better for everyone. Once everyone gets moving in the same direction, that becomes the baseline, and the web is a better place. We’re seeing that start to happen with HTML5. And despite the “Flash is dead” rhetoric, HTML5 will be a good thing for the web. Things like playing basic video and doing animation/vector graphics are so simple and yet so integral to the web experience that they should have been done in an open standards way a long time ago. But if Flash didn’t exist those things wouldn’t have become as important as they did as quickly as they did. And even now, as the web tries to move forward, Flash is being used as the fallback so that the web can evolve even if not everyone in the group buys in.

To me, that says that Flash will always have value. We control the platform so we can keep innovating and pushing the web forward in our own way. Maybe that’s content protected video, maybe it’s P2P support, maybe it’s a binary transfer protocol, maybe it’s hardware acceleration, maybe it’s writing your own filters and blend modes, and maybe it’s real-time collaboration. Eventually, the open web will incorporate all of those things. But I still wish there was more cooperation between the companies who have technology core to the web and the open standards groups who create the future of the open web. If nothing else, the open standards organizations can see what features stick and which don’t so that you don’t waste valuable time trying to standardize something users don’t want.

In the end, everyone wins. Flash won’t die, Flash developers can still be on the cutting edge, and Adobe will continue to support designers and developers on both sides of the open web/Flash spectrum. We’re all part of the web ecosystem in our own ways. Just like any ecological system, if one side goes extinct, the other is going to suffer.

AIR 2 and Flash Player 10.1 Betas now Available

Tonight we’ve released the AIR 2 and Flash Player 10.1 betas on Adobe Labs (direct download links for Flash Player and AIR). This is the first time we’ve simultaneously released the desktop (AIR) and browser (Flash Player) runtimes for all three platforms (Mac, Windows, Linux) at once, which is a great milestone for the Flash Platform. So what is this release and why should you care? One thing to note is that this is just the desktop runtimes, not any mobile runtimes. Those will be coming later. Luckily a lot of the work we did for mobile in terms of adding new APIs and optimizations are all in these releases so you’ll still get a lot of the benefits.

Flash Player 10.1

Lots of new stuff in Flash Player 10.1 including the multi-touch APIs, the performance gains, and some new networking APIs. The biggest thing (IMHO) with this release is the huge, huge memory improvements. Kevin showed the slide at MAX but it’s worth mentioning again. Without any code changes you’ll see significant improvements in memory with Flash Player 10.1.

flash_player_mem_footprint

AIR 2

air_logo_cloudsThe AIR team has been kicking all kinds of ass and I think AIR 2 is going to be a great release. One of the things we heard over and over again after AIR 1.0 was that people wanted more access to the native APIs of the operating system. AIR 2 brings a lot of that. Now you can open up a file with its default application as well as invoke native commands with the new NativeProcess API. We’ve also added the ability to create a socket server inside an AIR application and monitor changes to mounted drives. Plus a lot more. And you get all of the performance enhancements (and more) from Flash Player 10.1 so it should be a lean, mean AIR experience for end users as well.

Developing with the new Runtimes

(Update Christian has a list of AIR 2 resources that will help.) We won’t have a new Flex SDK for these runtimes yet so it’ll take a tiny bit of manual work to add support for the developer tools and the new runtime. Nick Kwiatkowski has a great screencast up for using the AIR 2 SDK in Flash Builder. It basically involves creating a copy of the Flex 4 SDK and then manually copying over the AIR SDK so it overwrites the AIR 1.5 SDK that ships with Flex 4. On the Flash Player side you’ll have to grab the playerglobal.swc and replace it in your Flex SDK.

I’m pretty excited about this particular set of runtimes. Talking to developers it seems like AIR 2 hits the mark and helps them accomplish more. Seeing the foundation put in on Flash Player 10.1 to create really great mobile experiences is also exciting. As always make sure to provide any feedback or any issues you run into over on the forums.

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.

Flex Momentum in Higher Education

educause_2009Since this week is Educause I thought it would be a good time to talk about some of the momentum we’ve been having with Flex in higher education. I came from the higher education side of the industry so it’s really great to see Flex do well. It’s major props to our education teams and Terry Ryan, who has been doing the evangelism side of higher ed, that this year has been so good.

  • Over 70,000 downloads of Flex Builder. That’s a combination of student downloads, faculty downloads, and lab seats.
  • Around 30,000 page views for our RIA teaching resources site which includes course project information, best practices, and other information to let professors incorporate RIAs into their curriculum.
  • In a survey of faculty at mostly 4 year graduate and undergraduate institutions we found that 52% are requiring Flex Builder in their courses and that 85% of them are using it to teach about rich Internet applications. Most of the faculty came from computer science and multimedia programs.
  • A number of technology partners in higher education including Stanford, Carnegie Mellon University, MIT, University of California – Berkeley, University of Missouri, and University of Southern California.

We’ve also got some interesting things going on at MIT, Stanford, and Berkeley. All of them have integrated Flex into the coursework in design interface classes (an example MIT course and an example Stanford course). Rochester Institute of Technology is planning on having some of their students do guest blog posts for InsideRIA. The University of Missouri has been working with our developer program and has run a couple of student contests including one that has students using the beta 2 of Flash Catalyst to create interactive content. One of the other cool things is that a lot of the schools are using Flash as a way to be on the cutting edge. RIT, Purdue, Georgia Tech and the Vancouver Film school are using Flash to research multi-touch and augmented reality projects.

It’s great to see Flex in every part of higher ed from directly in the curriculum for classes to downloads for lab seats so that any student can go and experiment with Flex. Growing the base for Flex from the education side means more interesting Flex developers, more tinkering, and ultimately a better ecosystem for the Flash Platform. It will be great to see the momentum carry into 2010.

And of course, if you’re a graduate getting ready to enter the job market, it’s a pretty good time to be looking for Flex jobs.