One of the highlights of the 2007 Adobe MAX (developer's) conference for me was the demonstration of Adobe's next-generation prototyping and developer/designer tool code-named "Thermo." It's a great example of rapid application development: designers (or developers like me with limited design skill) can quickly prototype a Flex application, even going so far as to import an composite image from Photoshop and having the tool recognize the controls in the image and convert them in to real Flex controls. The tool is smart about watching what you're doing and the controls you are laying out and offers to, say, turn a series of repeated controls in to a real repeater in MXML. It's helpful in a good way, not a Microsoft Office Clippy way.

If you haven't seen a demo of the tool, there's a video from C|Net's Web 2.0 coverage. Thermo has a lot of promise, and I hope it can make good on that promise because if it does, it will make developing Flex applications that much easier and faster.

So this is pure conjecture, but it struck me this evening: Could Apple's much-anticipated iPhone SDK in fact be Adobe's AIR (Adobe Integrated Runtime)?

The arguments in favor of this possibility:

• Apple wants an SDK that will protect the core iPhone runtime. Jobs made a very specific point during his announcement of the iPhone SDK that Apple has to make very sure that whatever SDK they release isn't going to allow third-party applications to crash the iPhone. AIR provides a separate runtime for applications that function very much like (at least on a Mac or PC) desktop applications: there's support for file system access, drag and drop from the host operating system, a simple, local database, and more. You can make rich, desktop applications using AIR with a very low likelihood of crashing the host OS.
• Consumers and developers alike have been demanding support for Flash on the iPhone since it launched last year. AIR is built on top of the Flash player (and brings PDF reading support to the table as well), so if AIR is the solution that's chosen, Flash becomes possible/enabled within Safari on the iPhone. That would make a whole lot of people happy.
• The iPhone OS is not the same as Mac OS X. It's not clear that you could compile applications in Objective-C and get them running on the iPhone. AIR lets you write applications in Flex, Flash, or HTML/JavaScript. This is a path that Apple has already begun to push developers down with the initial release of the iPhone, claiming that developers should write Web-based applications.
• Safari is based on WebKit. AIR uses WebKit as its HTML rendering engine.
• Apple has gotten consumers used to taking "Web pages" from Safari in the iPhone and turning them in to icons on the main iPhone screen. They could easily customize Safari on the iPhone to offer the same option when AIR installation badges are discovered on Web pages that users surf to using Safari on the iPhone.
• It's unlikely that Apple would allow third-party developers to tap in to phone functionality even if their SDK isn't based on AIR. That's the domain of AT&T and AT&T, I'm sure, will do everything in their power to control the data and services that relate to phone activity. Of course, if Apple's iPhone SDK is AIR, then third-party developers could write VoIP applications, even those using libraries like Ribbit. I don't think Apple cares about that. AT&T does, but Apple just wants to sell more devices and get people using the Internet with their devices. AT&T ultimately needs Apple and Apple's exclusive agreement with them than Apple needs AT&T.
• Apple will want a secure, controlled way of delivering third-party applications to the iPhone. AIR allows for certificates and digital signing. Adobe plans to have a marketplace for AIR applications, and Apple could use iTunes to do the same thing.
• Just a coincidence: Apple's iPhone SDK is due at the end of February. Adobe have made it quite clear that they're winding down Flex 3 and AIR 1.0 development right now. The timing is interesting.

The arguments against this possibility:

• The more developers who write in Objective-C for the iPhone, the more developers who know Objective-C, and the more developers who could then write for the Mac OS (and any device that runs the Mac OS, including the AppleTV).
• Apple will want a secure, controlled way of delivering third-party applications to the iPhone. Apple will probably use iTunes for this. They wouldn't want anyone else delivering applications to users of the iPhone, as control of the whole experience (from opening the box to making your first call) is critical to their corporate culture. Letting people install applications from any Web page with an AIR install badge would probably not sit too well with them.
• Putting Flash on the iPhone helps bolster the supremacy of Flash Video. Apple has a lot invested in QuickTime, and uses QuickTime to deliver its audio and video content (including anything that plays on an iPod). Apple is banking on broadband connections to deliver HD content anywhere, using MP4 codecs played back within QuickTime. I'm not so sure they're willing to cede that to Adobe by putting Flash on the iPhone.

• The Flash player may be too power consumptive for good performance on the iPhone. I doubt this, because QuickTime decodes video just fine on the iPhone, but it's possible.

I'm sure there are more arguments against this, but it's an interesting possibility.

Comments?

It's been a while since I've posted about software development or ColdFusion, but I have a few blog posts percolating away about the design of Web-based software. In the meantime, it looks like Adobe is finally going to do something about the craptacular state of development tools for my language of choice for Web-based apps: ColdFusion.

ColdFusion (CF) has long been in need of a truly capable, responsive, rock solid editor for the language and the frameworks that go along with that language. Eclipse and CFEclipse are great projects, but they're still rough around the edges in many ways (hello, no drag + drop?!). Many vendors make excellent plug-ins for the Eclipse platform that really assist the development process, but no commercial products exist for real ColdFusion development. The team behind CFEclipse has done a great job on a volunteer basis, but more is really needed. And Adobe should step up the plate. They've done it for Flex/ActionScript, so they can do it for ColdFusion.

Adobe just opened a survey about editors for CF. It's worth the time of anyone who's a CF developer to fill it out and help them make a tool that will help you in the long run.

I just sat through an hour-long session on the new Digital Rights Management (DRM) features available in Flash Media Server 3, the "Moviestar" update to the Flash player and related technologies. Throughout the session, AIR and the Adobe Media Player (AMP) were mentioned over and over as the delivery applications for DRM protected content using the Flash Media Rights Server. I asked if the same set of protections would be available in Flex or ActionScript 3-based Flash applications. The answer: no.

A lot of us who deliver content in Flash and, specifically, Flash video, have been waiting for a DRM solution for Flash video. I'm no fan of DRM, but a lot of the people who create content for the applications I build really want to protect (and monetize) their intellectual property, and I respect that. The DRM solutions we've been waiting for years for from Adobe (and Macromedia before them) were supposed to solve this problem.

Except now, we have to use AIR (Adobe Integrated Runtime) or the Adobe Media Player (which is an AIR app) to utilize the only DRM solution available for Flash video.

>.<

My users shouldn't have to download another application (AIR or AMP) to play back video content that I and my clients need to protect. I don't want to use AMP for my streams. I want to create an integrated environment in which my content is played, and not force my users to go outside that environment to view video. Adobe says that they are all about creating "engaging experiences," and making users hop from one application to another isn't exactly engaging. I know that I can make my own AIR app and make things as seamless as I want them to be, but user will still have to download AIR and that, in many situations, can be a big hurdle, if not downright impossible (hello, locked down desktops!).

I can understand needing the Flex framework to do this, but the what is so OS-integrated-specific about their DRM code that it has to be done in AIR? The rest of the AIR-specific classes make sense: drag+drop, local database storage, file system access. Sure, they have a secure local storage for DRM licenses in this new setup, but that's hardly necessary and something that could simply be turned off if the calling application was a Flex application rather than an AIR application. It seems to me that Adobe said "Hey, let's make them use AIR to drive AIR or AMP adoption." rather than creating something that's truly flexible.

Oh, and if DRM is super easy in Silverlight (which it more or less is), that's only going to solidify Microsoft's market for DRM-encoded content on the Web.

A few months ago, rumors began that Adobe was going to create its own online Office suite. I didn't think this was such a hot idea then, and I still don't, but there is something I hadn't considered before.

Adobe acquired Buzzword yesterday. Buzzword makes an incredibly capable online word processor using Flex. It covers all the basics of word processing and has some amazing layout and text flow capabilities for an online application. Adobe's acquisition is curious, however, because word processing, nor other "Office"-style applications, is not Adobe's strength.

At first it seems that Adobe is going the whole online Office route just to have another set of "services" or "online subscription applications" to sell to make analysts happy. As we all know, no technology company can possibly survive in to the next decade without having hosted services at their core because desktop software is going to die an immediate and horrible death, right? My flippancy aside, there is, of course, money to be made in hosted services and the flexibility and portability of hosted services sure is nice. Adobe could, theoretically, build an online Office suite that would capture a niche that didn't really need all the power of Microsoft Office or the bloat of OpenOffice — but Apple's already there with iWork. It's not an online app, of course, but I don't really think that's actually what Adobe is trying to do.

On the Future of Word Processing

Word processing is dying.

Let me clarify: the tasks long considered core to Word processing are dying.

Word processing has traditionally been defined by a couple of core, and fundamentally similar, tasks: writing letters, writing reports, and writing legal documents. Email has begun to kill off the traditional letter. Emails can still be formal, and carry a similar legal weight to letters. They're not equivalent, but it's getting there. Legal documents which require binding signatures are very much possible with another tool you may have heard of: Acrobat. With a law which went in to effect in the Clinton administration, it's perfectly legal to sign a legal document digitally, and a good number of companies are doing that. Reports require as much word processing as page layout, but fewer and fewer companies are, for example, sending out annual reports to stockholders. They point you to their Web sites either for PDFs created in a page layout application, or for richer, Web-based experiences. Students who create reports or assignments for school are beginning to generate online reports in wikis, blogs, and other rich-media formats. Slowly, but surely, reports are moving online and being bound to the rest of the Web through links and embedded media.

The digital divide still remains a huge obstacle to this movement, and the propensity of humans to resist change at every turn means that office workers will still fire up Word every time they want to make a newsletter or flyer. But the movement from traditional word processing (and the tools which enable it) to Web-based, rich-media publishing is happening, and users will only want the flexibility and freedom publishing on the Web, linking deeply in to the rich resources available to them off the desktop, in greater numbers.

So Adobe could have acquired Buzzword as a cornerstone for an Office suite. They could have just wanted their engineers because they are extremely talented. Or, perhaps (and when you look at all the improved text support functionality coming in the next version of the Flash player) Adobe is positioning themselves to welcome those who want to create online documents in a flexible, easy-to-use, highly productive environment. Not a word processor, not a blog, and not a wiki, but a combination of the three. Those who want customization and control will no doubt look elsewhere, but Adobe already is doing online editing for photos and videos, so why not text-based documents which link deeply in to the rich media of the Web?

I've never been a big fan of Fireworks, so haven't used it very much. Once I saw the MXML/Flex export from Fireworks 3 back in beta, however, I was very impressed and finally saw a use for the app. In a nutshell, you can prototype Flex UIs using Fireworks and then export the MXML from Fireworks and add your logic in Flex Builder (or whatever else you choose). Pretty handy.

What I didn't know was that you can do a lot more than just lay out the MXML. You can do a lot of styling work in Fireworks (where some tasks are easier than in Flex Builder) and then also export that information as well. Peter Baird wrote a good, short article on how to use Fireworks 3 for Flex UI prototyping on Adobe's Developer Center.

I don't do a ton of UI design work myself (I have great people on staff who are so much better at it than I), but when I do need to lay some stuff out, Fireworks is a handy tool — especially for prototyping and hiding and showing layers of the UI really quickly. There's even a Flex Style Explorer for Fireworks which helps to make sure that the work you do in Fireworks translates seamlessly over to Flex. Again, very handy.