Real World Computing

True web scalability requires a return to distributed authoring, focused on content production and not design. Macromedia, Dreamweaver's original developer, did come up with a solution in Contribute, essentially a return to Berners-Lee's original concept of a browser that's also an editor. The problem is that non-expert workgroup members need to be able to safely edit pages, but post-Netscape these are complex and design-rich compared with the inherent simplicity of Berners-Lee's original HTML. Contribute therefore needs a sophisticated web-editing engine (based on Dreamweaver's) along with a system of centrally set permissions and templates to control just what the end user is allowed to edit. A designer creates the site framework using Dreamweaver, then enables content creators themselves to update it.

Access all areas

Contribute restores some scalability by being semi-centralised and semi-distributed. This works for some kinds of site, but for many it merely falls between the two stools of browser-based and Dreamweaver-based authoring: it's semi-expensive, semi-detached and semi-complex, offering neither one thing nor the other instead of the best of both. And there's an even more fundamental problem. Contribute attempts to solve the distributed content provision problem, but provision is only half the story: once provided, content has to be made as accessible as possible.

In Berners-Lee's original vision, accessibility was elegantly simple: you added your page to the web via a single link from a parent page. This meant your content could be found, but that didn't mean it would be found. To maximise the probability of your content being discovered and read, such a single link is woefully inadequate - you need as many sensible parallel routes to your content as possible. In practice, you have to add links from multiple parent pages, usually with taster graphics and teaser text to encourage click-through, and you should also provide direct links on every associated content page. This benefits visitors already at your site, but is also crucial to help search engines understand and categorise your content, and so boost its ranking. Cross-linking both delivers more traffic and ensures more visitors become readers and stay on your site for longer.

This secondary web of links spun around the primary web of content pages is almost as essential to good web design as the content itself, but such cross-linking isn't scalable. Updating every associated page with new links every time you post a new page can take longer than designing the page in the first place, and the bigger the site, and the more potential routes users can follow, the more time it will take. And you can't expect your content contributors to understand, let alone take on, this task. So we're forced back into the bottleneck of inefficient centralised management, but this time with no hope of any distributed alternative. So why not turn to an efficient centralised solution?

Even when Berners-Lee first proposed the web, he imagined server-based "gateway programs... generating a hypertext view of an existing database". Such data-driven systems instantly solve both the content and linking scalability problems. Adding content to the site is handled through a simple database entry form, which requires no expert knowledge and so can be open to anyone in the workgroup. Navigational links dished up to end users are created on the fly based on the content available and factors like the pages recently viewed. Put these capabilities together and you can produce a truly scalable site such as Amazon, where the more content there is and the more the site is used, the easier it is for end users to find what they want thanks to intelligent cross linking.

Continued....