JD's Forum

I'm really glad that work was invested in Contribute—for years I've been hearing from people how they need a sane way for their clients to update parts of a page. This thread comes up a few times each week in the various mailing lists and newsgroups, and always sparks about fifteen replies ranging from "teach them Dreamweaver" to "write something in PHP" to "I saw this ActiveX doohickey" and so on. There hasn't been a general solution to this problem of client updates.

When HTML started it was very approachable—just a set of simple tags. Anybody could learn it. Now markup is much more complex—stylesheets, XHTML, validation, accessibility, server-side logic, and the rest. It takes serious investment to learn. With Contribute I think there's a way to get back to the original "every reader a contributor" theme of the World Wide Web, while still retaining the presentation and functionality features we expect in modern websites.

The basic idea of having a simple client to respect Dreamweaver templates is straightforward enough, but there were a lot of tweaks added through development: a simple UI that office workers would be comfortable with, the changes in templates in Dreamweaver MX, the encrypted e-mail setup process, the integration with Microsoft Office file formats, and more.

As important as Contribute can be in the short term, for current business needs, I've been wondering about the possible longer-term social effect of publishing with Dreamweaver and Contribute.

We now have a way to efficiently let a group publish live to the world. Wikis and blogs both do this too, but Contribute does this a little differently:

• Wikis have malleable inter-page structures with fixed template and editable areas that are widely separated within a single page.
• Blogs let a group of writers contribute to a single chronological stream of items, and don't usually support multipage sites.
• Contribute lets a web team create the structure of a site and specify particular areas of various pages where particular subgroups can maintain particular content items within each page.

Granted, we'll only see sites adopt this approach over time... it won't be an overnight revolution. Blogs were around for years, but it wasn't until the September 11 attacks that demand for better news analysis pulled blogs to the forefront. However, with the vast number of sites already produced by Dreamweaver professionals, and the low cost of entry to enabling group-editing by Contribute, I suspect we'll see this approach creep rapidly into real-world deployment.

But I still don't have a clear picture of which sites will first show the benefits of fast collaborative publishing, and which sites will show surprising uses of fast collaborative publishing. Here are some traits which may characterize the first wave of sites that fully exploit Contribute:

• The site will be a group effort, rather than an individual effort—some people will be specialists in the site design itself, while other people in the group specialize in the knowledge which the site presents.
• The earliest adopters will likely have presentation requirements: they may need to guarantee accessibility or dynamic publishing or multi-environment viewing, any of which are sufficiently complex to bar content contributors from modifying the whole page themselves.
• Such sites will contain information which does change regularly, and which may not change at predictable times or which may need to be updated on a short turnaround.
• The sites that move first to Contribute will likely be those whose changing content is integrated into the presentation. A newspaper could very well continue to store discrete articles in a database, because a newspaper's changing content elements remain separate from each other and separate from the boilerplate on the page. But group sites that don't consist of just a precession of separate articles will likely move faster to Contribute.
• New groups of people will be able to publish to the web... there will be more egalitarian access to distributing your thoughts to the world. Sites which can benefit from more diversity in authorship may move to Contribute more quickly than those whose authors are restricted to me current class of web authors.

I can see a separate group of Contribute-based sites, where the site designer and the content contributors do not work together every day. This is a large group, including restaurants, stores, charities, and sites done pro-bono. I'm guessing we'll see a general improvement in such sites which use Contribute, as it becomes much less expensive to update the information within a page. This improvement will be gentle rather than abrupt, however... I think this may be the same type of site, rather than a new type of site.

Will people use Contribute for blogging? They might, but I'm not sure yet what advantages they may see over blogging software. Will people use Contribute for discovery and clarification of ideas, as you could with a Wiki? It's possible, because relatively few use Wiki software yet, and if they're already comfortable with Contribute then I could see them migrate into a Wiki-like use.

But what other types of publishing might evolve when it becomes easier to have both control and timeliness in a site?

There are social aspects I don't understand yet. Different people in a group can be given different permissions for editing different parts of the site or a page. Will this be an important foreground part of many Contribute-based sites, or will it be a background feature? Will the ease of working with Microsoft-based formats influence the types of sites we see? Will the extensibility and customization of Contribute have a large effect on the ways people use this publishing environment?

I'm really interested in hearing your thoughts on how you could see things evolving here. I'll have an item open in the November 11 section of my blog, and if you could drop a comment there then I'd appreciate it, thanks!

As an aside, I've been really impressed by what the beta-testing team has done here this time. It's hard enough to figure out potential problems when you're just dealing with new features in an old tool, let alone in a new tool, or one which will be used by a new audience. Some of them even had time to write case studies, best-practices, and other articles for this issue of DevNet. The guidance offered by these close partners during beta had a substantial effect on Contribute's development, and I'd like to personally thank the people who invested their time in this tool for us all.

(If you'd like to work on a Macromedia beta team yourself, then here's the entryway... finding problems and describing them so that others can reproduce them are the two critical skills in beta-testing.)

New software tends to change rapidly, so we need your feedback on how you'd like Contribute to change. The first few versions of a tool usually arrive quickly with large increases in what they can do. After a few thousand hours of engineering in a tool, the incremental changes aren't as great, and more work needs to be done on backwards-compatibility, but new initiatives like Contribute tend to change quickly. Please let the team directly know how you'd like Contribute to change for your own work.