Content is king

Last month, I argued that the future of web design lies with XML rendered in a player rather than HTML interpreted in a web browser, not for the Flash-style bells-and-whistles this enables but rather for its potential to improve the web’s core function of handling text-based content. Style may matter, but substance remains paramount. However, such rich typography, allied to intelligently adaptive, multi-column paginated layouts, remains a long way off, as before we get there the Flash and Silverlight players will need to provide the requisite text handling, prove their worth and achieve ubiquitous distribution. Only after all these stages are successfully completed can Rich Internet Applications replace traditional websites. The humble browser and HTML page will still be with us for at least five years more – an age in web terms – so how should web designers make the most of them today?

This is a question I’m regularly asked, and my immediate answer is that “design” is actually a secondary issue: no-one visits your site just because it looks good; they want content, occasionally multimedia but overwhelmingly text. The job of a web designer is to make this content as accessible as possible, both to human visitors and to search engines.

Assuming you have content that users want to find, the next question is: what’s the best way to create HTML pages that will contain that content? For ten years my answer has been to buy a copy of Dreamweaver, which is unequalled for its combination of design power, coding functionality, support for web standards, and integration with Fireworks and Flash. Recently, though, I’ve become dissatisfied with this answer, not due to any failing of Dreamweaver, which remains the best desktop web-design application. No, the problem goes deeper: websites just weren’t meant to be produced like this!

As discussed last month, Tim Berners-Lee originally devised the web to help CERN’s researchers locate existing information, but crucially also to contribute new content to the shared pool. HTML’s simple content-focused, tag-based approach and the distributed nature of the web as linked standalone HTML pages together meant that anyone could quickly create pages and tie them to the existing web structure. The first web browser, Berners-Lee’s own WorldWideWeb, was also an editor that allowed any member of the workgroup with file: as well as http: access to contribute and manage content. Web browsers were originally intended to create content as well as consume it.

Other early browser developers failed to grasp this fact, but technically literate authors could simply Get and Put their files using FTP and edit their HTML in Notepad. All that changed with the arrival of Netscape and its introduction of and

tags to provide basic typographic and layout control. Users now needed to view their pages while they worked, and needed help to avoid mistakes – misplace a nested tag and your page fell to pieces. So the dedicated wysiwyg page editor was born, culminating in Dreamweaver. There were some advantages, as appearance is important and the web would never have taken off to the extent it has without Netscape and Dreamweaver making it attractive. But no longer could users freely and easily contribute and edit content as part of their browsing experience – you now needed an expensive, detached expert-only authoring app.

This wasn’t seen as a problem during the years of explosive web growth, but the new approach had one fundamental flaw: a built-in efficiency ceiling. Berners-Lee’s web could grow in an organic, decentralised fashion, with all participants creating and adding data, but dedicated authoring tools such as Dreamweaver centralised authoring, making a single webmaster responsible for each new page and edit, for building an entire design-rich site. The supply of content – the very lifeblood of the web – was throttled.