Desktop design

Last month, I looked at the history of desktop publishing (DTP) and its effect on paper-based design, but the 1984 launch of the Apple Macintosh and its Graphical User Interface (GUI) also opened up an entirely new publishing medium that’s set to become even more important than paper – the computer screen itself. The Mac’s significance for screen-based design was that it pushed aside the text-only, character-based PC displays then dominant and instead treated the computer screen like a sheet of blank paper, right down to having black pixels on a white background. Treating the whole screen as an addressable bitmap enabled pictures and, most crucially, multiple typefaces to be presented in rich onscreen layouts.

At launch, the Mac’s bitmapped display and its dot-matrix ImageWriter printer operated in perfect harmony at 72dpi, so the same bitmapped fonts could be used on screen and paper. However, the print quality simply wasn’t acceptable, and bitmapped fonts weren’t scalable – bitmap-based rendering required storing a version of every typeface and style at every possible point size, which quickly became unworkable, especially at higher resolutions. This impasse was broken in 1985 when Adobe’s PostScript PDL (Page Description Language) moved away from bitmapped to programmatic vector-based fonts. PostScript describes both page layouts and scalable fonts in mathematical terms rather than as arrays of pixels – every page is an executable program that generates the desired final appearance (effectively a full-page vector drawing). At a stroke, pages became resolution-, device- and platform-independent, based on fully scalable Type 1 typeface outlines.

PostScript offered a brilliant solution for highly designed, quality paper output, so the next logical step was to use it to generate screen output too, which is exactly what Adobe provided in 1987 with Display PostScript (DPS), created in collaboration with Steve Jobs (who had just been ousted from Apple) for use on his new NeXT workstations. The most important advantage DPS provided over a bitmapped GUI was that it enabled Type 1 typefaces to be rendered at any size onscreen as well as paper, and its resolution independence meant a 24pt font would actually appear as such on screen. Moreover, future higher-density screens would provide more pixels to render each glyph, so improving onscreen quality. In short, Display PostScript offered a richer, more faithful and future-proof architecture, which, most crucially, was platform-independent and so could be shared with other vendors (for example, on IBM and SGI workstations, as well as NeXT cubes).

However, writing to the screen proved much harder than writing to paper. For example, rather than its target being a single, fixed sheet of paper, a screen description language is faced with multiple, variable-sized, variable-zoom windows. DPS needed to collaborate with host windowing engines like the Unix-based X Window System, which added even more layers of complexity. Plus, DPS needed to deal with user interactions, like hit detection, and support programming languages (for example, to wrap Display PostScript code within C functions). The complexity and processing demands increased by an order of magnitude compared to print PostScript.

Display PostScript also hid a further, fatal flaw: its major strength was its ability to provide high-quality scalable fonts onscreen, but this broke down at small point sizes and low resolutions, where there just weren’t enough pixels to play with, resulting in dropped features and letter stems of varying weight. This can be cured by adjusting the shape of each glyph to the bitmap grid available, which is exactly what Adobe Type 1 fonts’ hinting system achieved, but Type 1 hinting was tailored to the LaserWriter’s 300dpi output and inadequate for the problems of even lower-resolution screen rendering. So for the most important part of onscreen content – the body copy – vector-based DPS had to revert to hand-tuned, bitmapped fonts!
Display PostScript found a temporary niche in the workstation market, but it was too far ahead of PC processing and display capabilities to go mainstream. In any case, neither of the two major OS developers for PCs were interested in ceding such a critical function to Adobe and paying licence fees. Instead, in 1989, Apple and Microsoft – although at the time engaged in a bitter legal battle over the Windows GUI – came together to develop the next step towards WYSIWYG computing. They decided to cut Adobe out of the loop, with Microsoft developing a PDL to replace PostScript and Apple developing a scalable font format to replace Type 1. Microsoft’s TrueImage PDL never amounted to much, but Apple’s TrueType proved hugely significant, as it supported advanced, dynamic hinting that effectively hand-tuned vector font outlines according to the number of pixels available. The launch of TrueType in 1991 finally enabled everyday PCs to use the same vector-based typeface outlines to generate high-quality scalable output on screen as well as paper – a huge advance in GUI-based computing. And Apple effectively gifted Microsoft the technology that made Windows 3.1 its breakthrough success.

TrueType was superior to Type 1 for screen rendering, but the way Microsoft and Apple chose to deploy was actually a step backwards from Display PostScript. Rather than programmatically rendering each glyph’s outline, based on the display’s actual pixel density, TrueType outlines were employed to dynamically generate bitmapped glyphs at the desired size, based on a hard-coded nominal resolution (72dpi for Mac, 96dpi for PC, 120dpi for Large Fonts), and these were then used to write to the screen. This got around bitmapped fonts’ memory greed, made scalable screen fonts viable and created the GUI as we know it today, but unlike truly vector-based rendering it was neither device-, resolution- or platform-independent.

At first, this deficiency was barely noticeable: maybe text specified as 12pt isn’t physically 12pt-sized onscreen, and its size will vary from monitor to monitor, but it’s 12pt on paper, which is what counts. And when you upgrade to a higher-density, higher-resolution monitor, your onscreen text won’t get sharper but rather smaller, which is counterintuitive, but you can always zoom in to make it readable. And the fact that the vector font outlines used to represent a document are completely external to it won’t become apparent if the document never leaves the authoring system. In short, device, resolution and platform dependence simply weren’t important as long as computers were viewed as standalone tools for producing print output.

However, with the rise of networks, and the internet in particular, even personal computers became increasingly interconnected, which suddenly made these issues central. Computers became consumers of content as well as producers of print, and the screen became a new medium in its own right. Moving data electronically over the internet was simple, but how could you present that content faithfully onscreen across different platforms? Had NeXT-style systems based on the DPS vector-rendering platform become the norm, this would have been relatively straightforward, but on Macs and PCs – with their standalone bitmap-based GUIs – you couldn’t reliably specify text size, position or typeface. Not just between PC and Mac platforms, but even between one PC and another.

The challenge was to find a way to publish information across the internet onto any computer screen, and the groundbreaking solution was developed ironically enough on a high-end, DPS-based NeXT computer. However, rather than push the screen-design envelope, it took the exact opposite tack and returned to basics. When Tim Berners-Lee came up with the idea for the World Wide Web in 1989, he sensibly avoided the whole question of presentation. The HyperText Markup Language (HTML) he devised said nothing about typography or layout, instead applying itself solely to the markup of content features like headings, quotes and addresses, which a browser application was free to interpret however it saw fit. All text was rendered in the browser’s default display typeface, and the end user could set a default size to make sure text was readable and this simply flowed to fill the width of the browser window. In other words, HTML acted as if GUIs had never been invented and would even work on old-style, fixed-width, character-based terminals.
The enormous inherent benefits of HTML – global access, easy authoring, hyperlinking and so on – ensured the web took off as a publishing medium, but its complete lack of design abilities left plenty of room, and demand, for alternative approaches. In particular, in the networked world, it became increasingly anomalous that work created on a computer had to be printed out as hard copy to be reliably exchanged with its layouts, graphics and fonts intact.

Adobe, licking its wounds from the failure of Display PostScript and facing a post-TrueType collapse in licensing revenues, knew it was still sitting on the solution. In 1991, the company began work on Interchange PostScript (IPS), and two years later in June 1993 it was presented to the world renamed as PDF – the Portable Document Format. Naturally, what made PDF “portable” from platform to platform and system to system was its underlying device, resolution and platform independence, enabled by PostScript-based programmatic rendering of embedded scalable vector fonts. Thanks to these PostScript foundations, it was possible to create PDF files from any application that’s capable of printing and, more important still, thanks to the new cross-platform Acrobat Reader it was now possible to accurately render PDF files to non-PostScript printers and directly to screen.

PDF could act as “ePaper”, a universal electronic paper equivalent, and Adobe had created a second far richer cross-platform, screen-based publishing medium. However, PDF never replaced HTML as Adobe originally envisaged – its approach of using the screen as a window onto a printed page was just too awkward. A screen isn’t just a sheet of paper on its side; it’s a medium in its own right. PDF has an important role, but the web remains the most popular way to publish information to end users’ screens.

However, to fulfill its potential, HTML needed to be made a much richer design medium. Originally, this was done via undesirable workarounds and extensions, such as <table> tags to divide up the web page and Netscape’s <font> tag to specify a particular font size. Beginning in 1994 and continuing under the aegis of Tim Berners-Lee and the W3C, Håkon Wium Lie and Bert Bos created a dedicated style markup language, Cascading Style Sheets (CSS), that enables web authors to specify how they want their HTML (and these days XHTML) content to be presented by the browser. CSS doesn’t guarantee that the author’s wishes will be granted – for example, you can specify a particular font, but whether it appears still depends on which fonts the end user has installed – but it does make HTML a much stronger design platform.

Thanks to CSS and other important web-based advances, like the advent of data-driven pages generated by server-side scripting languages, HTML has become the most important screen-based medium by far. But it too has a fatal flaw: it employs a fundamentally page-orientated metaphor based on static, typographically crude text fetched one page at a time from the server. However, the dominant metaphor on PC screens isn’t based on pages at all, but rather on applications, and when interacting with an application the user expects rich content, highly designed and offering continuous interaction. And there’s absolutely no reason why such an experience shouldn’t be delivered over the internet.

The solution that emerged to provide this third and richest screen medium was developed by Macromedia, the developer of Dreamweaver, the professional web designer’s tool of choice for HTML authoring. Back in December 1996, when Macromedia bought up FutureSplash Animator, a tiny niche application for creating cartoons, no-one would have predicted what was in store for it when relaunched as Macromedia Flash. What made Flash and its SWF (Shockwave Flash) format different, and gave it its strength, was that it was built on vectors, which meant from the outset that its drawings, animations and graphical text were fully scalable and could be rendered efficiently and reliably on any supporting platform and device. Flash’s typographically rich, dynamic vector animations stood out from their static host pages, and the Flash player became a must-have download, thus creating a ubiquitous platform on which Macromedia was able to build.
In particular, by grafting on streaming audio and video support along with dynamic text and graphics handling based on an ongoing connection to the server (no need for page refreshes), Flash became a complete multimedia solution. Just as importantly, through the development of preset UI components and ActionScript, Flash was able to move from basic user interaction to advanced programmatic control and processing. The end result is that, while Flash can still be used to add the odd bell and whistle to an HTML web page, it can now be used to create advanced, content-driven, universally accessible Rich Internet Applications (RIAs).

Flash completes a holy trinity of screen-based media – HTML, PDF and SWF – that caters for internet-delivered sites, documents and applications respectively. To take advantage of them, all the end user needs is the necessary client software: a web browser, Acrobat Reader and a Flash player. From the professional designer’s perspective, things have become even simpler: after its recent takeover of Macromedia, there’s now just one vendor to deal with, Adobe. Its Display PostScript dream never materialised, but Adobe has nevertheless come to dominate the field of cross-platform, screen-based design through its applications, clients and supporting technologies.

So where does Adobe and screen-based design go from here? The obvious next step is to merge these three key media into a “universal client”, and that’s exactly what Adobe is proposing with its Apollo project, expected to see the light of day in early 2007. Current details are still thin on the ground, but it looks as though, rather than merging players, Apollo will take the form of an additional cross-platform runtime designed to make it possible to combine HTML, PDF and SWF content in any combination. The prospect is mouthwatering, the best of all worlds: the ability to mix rich static, dynamic and live content within layouts that combine fixed and fluid elements, all wrapped up in an intelligent, interactive interface.

In addition, the Apollo client will finally decouple the underlying technologies from the browser, allowing Adobe to provide a total and reliable standalone solution, which in turn will enable Apollo applications to run offline directly from the Desktop. This is exciting stuff, blurring the current distinction between site, document and application. Where Display PostScript attempted to offer a shared screen-rendering platform for text and graphics, Apollo runs with this idea to provide a shared platform for delivering all forms of rich and dynamic content, to both screen and paper, via advanced interactive applications hosted both locally and remotely.

Until it actually arrives, the full implications of Apollo for screen-based design remain uncertain, but the potential significance is enormous. In particular, rather than Adobe being cut out of the loop, suddenly it’s Microsoft and its browser and programming solutions that are in danger of being left out in the cold. In fact, Windows itself is threatened, as it’s no longer required to view and run Apollo apps, a fact that will interest handheld and set-top box manufacturers. If it succeeds, Apollo could repeat Bill Gates’ Java nightmare with a vengeance.

Naturally, Microsoft is planning to fight back – and on all fronts. The imminent launch of Windows Vista, with its associated WPF, XPS and XAML technologies and suite of Expression applications, sets the scene for the Mother of All Battles, the winner determining the future of screen-based design. It’s a subject to which I plan to return.

Related Posts

How To Copy a Slide’s Design in PowerPoint Why Can’t I Move Anything on my Figma Design? Here’s How To Fix How to Share a Design with You Team in Canva Minecraft Castle Design Ideas How to Sum a Column in Google Sheets [Mobile Apps & Desktop] Remote Desktop Connection Not Working? Try This How to Install a Second SSD on a Desktop or Laptop How To Remote Desktop to Ubuntu From a Windows PC The Best Remote Desktop Software