Midsummer Wrap-Up

Reaction to Contribute 2, FlashPaper, Product Activation, Browser Changes

Summer in the northern hemisphere is usually a slow time in the technology world. Not this year. This summer Macromedia had some announcements about upcoming offerings, and there was also a series of dramatic news items about HTML document browsers. Here's an early recap of what I've been hearing in the online discussions.

Contribute 2.0

Macromedia Contribute is a bit of an anomaly. It's a new type of software tool, and these typically take awhile to catch on, for people to understand what they do. The first few weeks of discussion on the 1.0 version of Contribute did have some shakiness—some said "but I want it to edit text in databases not just HTML files", others objecting "but now I won't get my designer fees every time they want to change some text in a page". But I was startled during the Contribute 2.0 announcement to find that the overwhelming sentiment was a plain and simple "We love Contribute". I can't recall a similarly quick adoption of a new category of tool.

I think the main reason for such quick acceptance may be that the ideas behind Contribute were grassroots, bottom-up. There have been regular strong comments in Dreamweaver conversations for the last few years that we needed ways to have clients handle non-structural content chanages themselves... designers were complaining about having their schedules shredded with requests for minor changes, taking their time away from actual structural design and development work.

It's really the grassroots webdev community which is responsible for the birth of this tool. It just took the company awhile to catch up and deliver it. It reminds me in a way of the Dreamweaver 1.0 launch, where people were saying "we need something that just leaves the markup alone", and where there was rapid acceptance once a tool existed that did just that. For some types of work companies like Macromedia have to predict what will be desired, but in Contribute's case people were very clear about what they wanted before the engineering was started. That's my theory about the strong positive reaction to the 2.0 announcement, at least.... ;-)

The Contribute 2.0 cycle also shows something else about software creation—it's important to get something new out into the everyday work of people to find how it needs to change, and then to rapidly incorporate those changes. One of the big complaints about Contribute 1.0 was how so many people who wanted to use it needed secure transfer directly to public servers, rather than to protected staging servers for approval before pushing live. That's why the connection engine was rewritten for the 2.0 cycle. As a tool gets more mature people have a better idea of what they want it to do and feedback cycles become more deliberate, but when introducing something new the cycles usually come quicker and are more dramatic.

FlashPaper

This was a fun little surprise in the Contribute 2.0 announcements. "FlashPaper" is a system-level printer driver which lets other applications "Print to SWF", ready for insertion in an HTML page.

Like Contribute 1.0 it needs rapid feedback and change, but unlike Contribute people weren't expecting such a thing so I think it will require a little longer to identify exactly how people need it to evolve. Some changes are obvious—we need to get this printer driver onto more than just a few flavors of Windows, for instance—but I suspect that it will take a good amount of realworld experimentation by ordinary office workers before we accurately identify its full growth path.

The direct goal in this initial release is to make it very easy for regular content contributors to add info from varied applications into web pages made with Contribute. A spreadsheet, a word-processing document, an illustration, a data feed... getting these into a web browser with minimal hassle is the core task in this cycle. FlashPaper is part of Contribute.

I know that skilled Flash developers have been very excited by FlashPaper and are trying to think of ways to adapt and extend this initial version. I don't know in which directions it will grow first, myself, but I do know that we need to get a wide variety of hands-on experience to discover the most valuable changes to implement. It's tempting to predict, but more important to observe for awhile.

In early FlashPaper discussion I wasn't surprised to see it compared to Adobe Acrobat. I don't think this is a realistic comparison, but I can see how it would come up—we try to understand new things in terms of what we already know, and for "self-contained documents via web pages" everyone is already aware of PDF content.

Why are they different? Because of the nature of the distributed rendering engine. The Macromedia Flash Player's main goal is universal viewership, and for this the player needs to be very small, easy to download and update, transparent across multiple types of systems. Every byte counts.

Acrobat and Shockwave are similar in that both are large plugins, and both are viewable on the majority of consumer machines. But neither is as widespread as Flash, and most importantly, neither gets updated by consumers as quickly as Flash. That's why, in less than a year of availability, more consumers can view Flash 6 files than can view Acrobat 3 or Shockwave 5 files.

It's really, really hard to get the world to adopt a capability on their own machines. The searchability and annotations in Acrobat are great abilities, just like the bitmap synthesis or realtime 3D in Shockwave, but those extra abilities come at a cost of slower adoption.

It's demonstrably easier for the world to adopt and update a small browser plugin than a larger plugin... easier to update a plugin than your entire browser... much easier and faster to upgrade a browser than to upgrade an operating system. Universal realworld deployment is the key strength of the Macromedia Flash Player. It's difficult to go head-to-head on total feature lists with things that are much slower to deploy, and with time I think these comparisons with Adobe Acrobat will diminish.

Anyway, please do give us guidance over the coming months on how you need FlashPaper to evolve, whether it's localization or accessibility or bookmarking or customization or the myriad of other needs we'll all discover here. Thanks!

Product Activation

With Contribute 2.0 the company is testing "product activation", which is essentially a way to insure that a serial number is unique before running beyond the 30-day trial period. Macromedia is doing this to reduce the number of "pass-along copies" of a widespread office tool like Contribute. We'll need your help to make sure this is actually a hassle-free way to achieve this goal.

The software industry as a whole is moving towards such protection, but earlier implementations have had a mixed response. Some companies which have tried earlier versions have had great results with it, while others have had customer complaints and have had to remove activation. Although the Macromedia implementation has done major research and testing on previous attempts, there's still no substitute for widespread realworld testing.

If you create with Dreamweaver, I'd urge you to spend a little time at that Macromedia Product Activation Center and read up on how it works. If your clients upgrade or purchase Contribute 2.0 then you'll be in a good position if they come to you with their questions. (Ideally such questions would come to Macromedia directly, but in the real world they may contact you first, as their web specialist.)

Even better, get a copy of Contribute 2.0 yourself early on, so you can confirm that your experience matches the experience of beta testers. Matter of fact, if you use Flash and not Dreamweaver, buy a copy for FlashPaper... it's cheap, and we'll throw in Contribute 2.0 free! ;-)

The important thing is to confirm in the world that this improved implementation is actually as universally simple as it has been during testing. If there's a snag, then we need to know what we need to improve here. Thanks in advance for your help with this!

Browser changes

The Macromedia announcements were significant, but they took a back seat during early summer to discussions about the dramatic changes to HTML document browsers.

First AOL/Netscape and Microsoft announced a settlement of a prior lawsuit... then Microsoft announced that there would be no future versions of Internet Explorer for Macintosh... then that there would be no further versions of IE/Win for existing operating systems... after that America Online announced that they were halting their Netscape Navigator efforts.

The results seem to be that the "browser wars" are over with both sides dying off. Consumer browsing won't improve until they either (a) switch to another browser brand or (b) switch to a Microsoft operating system which won't be out for a few years yet.

Webdev people are in a particularly tight spot here. With HTML and JavaScript and CSS and XHTML and the rest, we're delivering documents rather than applications. It's easy enough to change the software on your own machine, but really, really hard to get the world to adopt a capability on their own machines. Having to change software brand or operating system is a particularly difficult task.

In practice, it's hard to see how to improve HTML delivery for the next few years. You can change your documents, but how can you change all the rendering applications "out there" on consumer machines?

From reading the early conversations I think a lot of webdev people were hoping that Microsoft would use its market-owning muscle to force consumers to upgrade somehow. This was always difficult with a standalone browser—many stats I've seen still show higher viewership in IE5 than in IE6. Having to install a new operating system, and possibly buying a new machine to run it, pushes improvements in HTML handling 'way, 'way off into the future.

There are lots of wildcards here. The recent Mozilla browsers are very good, as is Apple's Safari, and the Opera browser has been sturdy for years. Switching browser brands is certainly easier than switching operating systems or switching machines. Increasing security problems or increases in purchases of new computers or other factors could change the rate of enablement for new HTML features.

It might be that document browsing is "good enough" already—after five browser generations people can see static documents on the web, even though designers want more control or more adherence to ideal specifications. The news might push some sites to create web applications only viewable in IE5/Win. On the other hand, it might instead push more web applications towards delivering in OS-neutral, browser-neutral SWF when they want to do more than old browsers can handle.

It's too early for me to guess how these conflicting pressures will play out. One thing I know for sure, though, is that I can't recall a similar seismic shift happening in the web community before. I'm already seeing people react in a wide variety of ways, with some indicating a profound change in how they view technology development. Something significant happened here this month.

Submit feedback on our tutorials, articles, and sample applications.