Iconix: A New Face for RISC OS 5

Richard Hallas was commissioned to produce the new-look icon set for RISC OS 5, and explains in great detail what went into the designs

Please ensure that you view this article in a 16-million-colour screen mode. Use of a lower colour-depth will not allow the illustrated icons to be displayed correctly.

This is an exceptionally long article which would take quite a while to read all in one go. However, it has been broken up into many distinct sections which can be read in isolation, so you can choose which parts to read from the following contents summary. Clicking the entries will scroll the page down to the corresponding section heading, whereas clicking on the heading itself will return the view to the top of the page.

Prelude: background story

He was quite cagey to start with, and wouldn't tell me anything of significance until I had signed and faxed back a non-disclosure agreement (NDA), which he emailed me as a PDF file (a process that wasn't without its frustrations, as a recent thunder storm had upset Castle's fax machine). Our next conversation, though, revealed the need for all the secrecy: Castle had acquired the rights to RISC OS 5 and was planning to release a fast new fully-32-bit machine, with RISC OS 5, in time for Christmas.

"Which Christmas?" was the obvious, sceptical response. I might not have been so rude as to ask the question out loud, but it passed through my mind as almost a reflex reaction. Judging by what I'd seen at the MicroDigital press day I had every expectation that the Omega would indeed finally be in production by Christmas, but a new machine from Castle, featuring brand-new XScale-based hardware and a complete new release of the OS, sounded like a very optimistic proposition in such a short timescale.

Hindsight has of course proved that Castle met every one of its deadlines and released its new machine on the last day of November, in good time for the important Christmas market, whereas, at the time of writing (mid-January 2003), the Omega has seemingly still not appeared.

Anyway, I was understandably very excited by what Jack had to say, and was intrigued as to why he was telling me about it at this middle stage of the project. As I am known primarily as a writer and editor in the RISC OS world, I thought that perhaps my writing skills might be required for a manual, publicity or some other such verbiage. But no! To my great surprise and pleasure, Jack was interested in my graphical abilities. It's true that I have designed icons, user interface graphics and other artwork for a variety of programs over the years, and have occasionally written about the subject, but I had not expected Castle to be aware of my activities in this area.

The release of a major new 32-bit version of RISC OS, in the form of a powerful system based on modern hardware, not only provided the opportunity to introduce a fresh new look to the desktop, but also virtually demanded it. Castle had big plans for its new computer, and wanted something that looked impressive; a desktop that could appear professional and serious alongside the latest offerings from Microsoft and Apple.

Now, as it happens, a complete redesign of the RISC OS desktop is something that I'd really wanted to do for a decade or more. The old RISC OS 3 icon set actually had quite a lot to commend it, but it was a product of a time when a 16-colour screen was at the high end of a computer's display capabilities; the RISC OS 3 icons were barely different from the set supplied with the original RISC OS 2 Archimedes in 1988. So, by the time of the Risc PC's launch in 1994, with its true-colour display modes, the familiar RISC OS icons were already very long in the tooth and not making best use of the machine's capabilities.

Acorn did attempt to address the issue by commissioning a new icon set for RISC OS 4 (which would have made their début in the Risc PC 2, but were of course inherited by RISCOS Ltd for the launch of RISC OS 4). However, I have never made a particular secret of my personal dislike for the RISC OS 4 icon set; I felt that the designs were poorly executed and discarded a number of very helpful ideas which had been present in RISC OS since its earliest days.

So the opportunity to design a new set of icons for RISC OS 5, which would be able to modernise the look of the system whilst reintroducing some good ideas that had been lost, was a very exciting one for me, and one which I was keen not to miss. I was therefore highly delighted to be involved, and Jack put me in contact with Paul Skirrow, the software co-ordinator of the project, with whom I worked reasonably closely in the run-up to launch.

At this stage, of course, the IYONIX pc was known as the Tungsten Project. However, because my rôle would be a graphical one, it was necessary for me to be made aware of the final product's name and logo, which had already been designed. So I was, I believe, the first person outside Castle's direct employment to know about the final name and appearance of the machine.

The task ahead of me, whilst exciting, was also quite daunting, not least because of the sheer amount of work involved, the relative lack of time in which to do it, and the fact that other things were also going to make demands on my time. I had issue 10 of Foundation RISC User to prepare during September, and each issue usually represents around a month of solid work for me, so that would require a large chunk of my time. I also had my main annual holiday coming up, which would use up another ten days. So, given the sheer number of icons involved, it was clear that I had my work cut out; but the opportunity was far too good to miss, and I really wanted to do the job.

I therefore accepted the task with relish, and it took me until the last week in November (just prior to the machine's launch) to get through the complete set of graphics. The elements required included file icons, application icons, buttons for toolboxes, textures, window tools and other elements, most of them in multiple versions for different screen resolutions and/or colour depths. Quite a number of the icons went through a few revisions, too; one particular icon reached its twelfth version before finally being adopted! In total, including all the variants for different sizes and so on, I ended up creating well in excess of 1500 different icons (at the time of writing, not all of them have yet been seen in public).

So, that's my personal background to the story; the remainder of this article will explain the design goals and why some particular decisions were taken, within the context of previous RISC OS systems and the platform's current competition.

Design objectives

Those requirements may seem reasonable and sensible in themselves, but in fact they're really quite demanding. If I was to produce an exciting new look, to make good use of the new hardware and not appear too crude or amateurish alongside the likes of Mac OS X, how on earth would I also manage to retain familiar elements from a 16-colour system that was designed around a decade and a half ago? How should I strike a balance between looking futuristic and looking retrospective? The two objectives seemed diametrically opposed.

There were other design overheads too. Creating a new-look desktop for use in screen modes with 16 million colours is all very well, but RISC OS has always been very adept at allowing the user to choose different screen modes with different colour depths, resolutions and scaling (much more so than other platforms), and this functionality would of course still be present in RISC OS 5. So even though it's expected that Iyonix users will operate their machines almost exclusively in high-resolution desktop modes with 16 million colours, the icons had to be designed in such a way that they would still look acceptably good in fewer colours. In other words, they needed to degrade well to 256 colours, or possibly even fewer colours than that.

There are also practical difficulties in creating icons with huge numbers of colours in them: the more colours present in an icon's palette, the slower it is for the operating system to plot it, and the more memory it requires. Although such considerations are not terribly visible to the average user of the machine, they're significant nevertheless, and even on a machine with lots of memory and disc space available, one should still strive to be as efficient as possible.

So, I had to maximise the quality of the icons' appearance whilst minimising their memory overheads and allowing them to degrade well into fewer colours. The icons also, of course, had to be simple enough to be recognisable at small sizes whilst being clearly distinguishable from one another and yet also mutually consistent. In other words, there were rather a lot of often conflicting factors to bear in mind with the designs.

With all that in mind, let's see what I came up with and why. For the benefit of readers who haven't yet had the chance to see an Iyonix in action, and perhaps haven't seen a colour picture in a magazine either, the following image shows a screenshot of a RISC OS 5 desktop with a selection of the standard icons on view. It's limited to 800×600 pixels in size for easy viewing, and the quality has been degraded slightly because of using the JPEG file format, but it should give a good idea of what various kinds of icon look like.

The RISC OS 5 desktop, showing a reasonable selection of the new icons

Design principles

To recap on the most important set of points, though, I believe that icons should exhibit the following characteristics:

• Realism: icons should actually look like what they're supposed to represent;
• Clarity: the meaning should be obvious without the icon being overcrowded;
• Uniformity: sets of similar icons should be related clearly to one another;
• Individualism: icons should be sufficiently distinct to be obvious at a glance, even if they form part of a related series;
• Size: the size of the icon should be big enough to convey the necessary meaning, but not excessive;
• Colours: icons should use only as much colour as they need, and should avoid using lots of different colours just for the sake of being colourful.

The 'size' criterion was largely irrelevant to me because the icons had to be the same size as in previous versions of RISC OS (i.e. 34×34 pixels for standard file icons and so on). However, all the other points were extremely important for my designs.

In my previous article I also stated my belief that icons should feature good quality shading and anti-aliasing, and that their edges should be defined by the content of the icons themselves rather than by some artificial 'cartoonish' black border drawn around their edges. Now, whilst I'm certainly not deluding myself that my RISC User article could have had any influence on developments in the computing mainstream, it's nevertheless a fact that the latest versions of Windows and Mac OS (both of which have been completely revamped since the article was written) have followed exactly the ideas that I outlined, with realistic-looking icons, good quality shading and anti-aliasing, and an elimination of cartoony borders. This reassured me that my own approach to icon design was valid and in tune with current developments.

Designing in context

Windows XP

The problem is that Microsoft has gone overboard on the use of its four Windows colours. The latest version of its Windows flag logo is comprised of just four rectangles, coloured red, yellow, green and blue, waving in the breeze. In Windows XP, Microsoft has clearly decided to make a big feature of those four colours and design its desktop around them. So window borders use the blue and red colours, and the yellow and green are used for highlighting buttons within the windows; and many icons are based around all four of the colours (think of the MSN Explorer butterfly or the Windows Media Player icon, for example).

It sounds like a good idea in principle, but the practical result is a lack of subtlety and overuse of colour. So whilst I acknowledge that there are good things about some of the Windows icons in terms of how they're drawn, I wanted to try to steer clear of Windows' excessively colourful style.

The somewhat garish-looking Windows XP

Mac OS X

I'm a big fan of the Mac OS X appearance, known as Aqua (not every aspect of it, but many). Where Windows XP looks garish and childish, Mac OS X looks tasteful and professional. Why should this be? I believe it's largely a matter of restraint. Even though Mac OS X requires 16M colours to look good (it can cope in 32K colours but looks very poor in 256), it's essentially a monochrome design that uses a spot colour. In effect, its overall design is just black and white, but uses blue for important highlights; and on top of that, it uses colourful and photo-realistic application icons.

The results are very sleek indeed: there are soft shadows all over the place (including ones cast by windows), the icons scale dynamically and very smoothly, and there are no hard edges or borders in sight.

However, such slickness comes at a very high price in terms of system resources: Mac OS X needs a fast G4 processor to run acceptably well, it needs lots of disc space, and it really requires a bare minimum of 256Mb of RAM in order to do anything useful and run more than one significant application at a time. In other words, it's very wasteful of resources, in a way that RISC OS has never been. For instance, program icons are designed in multiple versions of up to 128×128 pixels in 16M colours. A single icon of those dimensions requires 64K.

But it looks great, and I felt it was the sort of thing to which RISC OS 5 could aspire, even if I was not trying to emulate it as such.

The very tasteful Mac OS X

RISC OS 2 & 3

Most long-term users of RISC OS systems remember the old-style RISC OS icons very fondly. Despite only having a sixteen-colour desktop available for 'normal' use (you could go up to 256 colours, but it put significant demands on the system in its earlier days), Acorn chose its colours very well indeed. It devoted half its palette to black, white and six intermediate shades of grey, which allowed text anti-aliasing to work beautifully and also allowed good shading to be included in icons. The other eight colours also complemented each other very well, with a couple of blues, greens, reds and yellows, which gave lots of scope for good use of colour.

Moreover, RISC OS also pioneered the 'monochrome with spot colour' approach that Mac OS X has now adopted. Window borders and contents, the screen background and so on were all in shades of grey, with a cream spot-colour for important icons, and other splashes of colour here and there in application and file icons. So that fundamental piece of design work was actually very astute.

There were other good ideas. Device icons were generally coloured cream (the 'spot colour') unless they were inactive, in which case they were grey. Applications such as Printers made good use of this by having several grey icons and one cream one for the active device. Similarly, the window manager lit up the active window's border by colouring its tools cream instead of grey.

So many aspects of the RISC OS visual design were actually very well thought out. The overall look of the system was let down more by the crudeness of some of the drawings, lack of attention to detail in many areas and the restrictions of the machines of the day, rather than by any inherent shortcomings of the basic design. But at least the RISC OS icons were distinctive and easy to recognise, and, being defined in just the basic 16-colour palette, the icons looked the same in all but the lowest colour depths and had stylistic consistency.

RISC OS 4

Device icons now became uniformly grey; the active printer became much harder to distinguish. The new-look window tools, introduced with RISC OS 3.5, had already compromised the lighting-up of window borders by restricting it just to the title bar, and disguising that to a degree by the presence of texturing. (An Acorn employee once told me that the company had subsequently decided it had been a mistake to restrict the illumination to the title bar alone, and I agreed with that point of view.) Now, with the latest icons, the cream 'active device' idea had been lost as well.

Perhaps worse, the file icons were much less easy to distinguish from one another. All 'system' icons were pale blue and looked almost identical; all bitmap image icons used exactly the same design (except for JPEG, which was an inexplicable exception). The only unique identifier took the form of a textual filetype label, which was written vertically and was hence quite difficult to read.

On top of that, I felt that the icons were drawn quite poorly. They had solid edges, and hence remained 'cartoony', but the edges were so pale that they blended into the window background. They had curled corners which looked flat rather than 3D. There was no real attempt at anti-aliasing. There was a limited attempt at 3D shading, but the colours chosen were generally so pale and close to one another that there was no sense of depth, and the overall effect was a curious mixture of appearing garish and washed-out at the same time. There were some quite nice ideas too, though, such as the corner-curl to make file icons look like files rather than just squares, and the use of an OS logo as an emblem in the corner of certain system file icons.

A further problem with the RISC OS 4 icons, though, was in their choice of colours. They had the full Acorn 256-colour palette at their disposal, but many icons used so few colours that they might as well have been defined in just 16 colours and not waste the extra resources required by 256-colour sprites. Moreover, the colours chosen were usually ones that did not translate well into desktop modes with fewer than 16 colours:Ýtry using a RISC OS 4 machine in a 16-colour screen mode; the icons look poor, and mostly go grey. Also, dither-patterns were used, for example in the pale blue backgrounds of system-file icons. Whilst dithering is a useful way to represent more shades in a very restricted palette (such as a 16-colour one), there seemed little justification for this with 256-colour icons. And on top of all that, there seemed to be little if any colour coordination between different icons.

So overall I was never terribly impressed by Acorn's RISC OS 4 icon set, and felt that it discarded more good ideas than it introduced.

Designing the RISC OS 5 icons

Rules for design consistency

1. Icons should not be over-complex, and where I felt that the quite simplistic original RISC OS icons worked well, I would produce modern recreations of the original icons. However, I would also produce entirely new icons, or significantly modernised ones, where I felt that the designs could be improved.
2. Any given 'class' of related filetype icons would have its own colour scheme, to help relate them to one another. The most important icon in the class (sprite file for bitmaps, Draw file for vector graphics, and so on) would be a 'full-icon' graphic containing an element from the primary editor used to create it (the Paint brush, Draw pencil and so on). Subsidiary icons would have the same basic colour scheme, but would also feature an appropriately coloured text banner at the bottom, and would lack the 'editor' element (e.g. no Paint brush or Draw pencil in JPEG and DXF files).
3. The number of colours used in any individual icon would not be excessive, and may be restricted to monochrome plus the icon family's basic identification colour (for example, 'system' files would be green). Visual sophistication would be achieved through use of subtle shading effects, anti-aliasing and soft shadows, rather than by excessive use of colour.
4. For both practical and aesthetic reasons, I would actually make a lot of use of the original Acorn Wimp 16-colour palette, even though it dated from 1988! As mentioned above, the colours it contains are very well chosen. Making significant use of those colours in my icons would achieve three major benefits:
   1. Existing users, upgrading to an Iyonix, would gain an immediate feeling of familiarity even though the icons were new and different.
   2. Widespread use of a limited set of colours imposes its own sense of order and style, which is a useful byproduct in a situation like this.
   3. Because those sixteen basic colours are all defined in the original 16-colour desktop palette (i.e. they're the only colours that can be displayed in a 16-colour screen mode), they are present in all colour depths from 16 colours upwards. So if my icons used these colours predominantly, with other pixels merely being subtle shades of these colours, the icons would automatically degrade gracefully if the user reduced the colour depth of the screen, right down to a 16-colour desktop.

In fact, on the last point, I ended up using a lot more basic colours than just the sixteen in the desktop palette; to do otherwise would have been too restrictive and unsubtle. Consequently, some icons degrade into very few colours better than others. Nevertheless, I did concentrate quite a lot on those original desktop colours, and the icons do degrade much better, I believe, than the RISC OS 4 set, even to 16 colours (which Iyonix machines aren't actually capable of displaying).

Optimised palettes

My solution was to use 256-colour icons, as in RISC OS 4; but unlike the RISC OS 4 icons, mine would have optimised palettes. In other words, I would define them as 16M-colour icons but save them with palettes that allowed the use of up to 256 arbitrary shades per icon. The inclusion of a palette definition for each icon would increase its memory requirements slightly, but only by a little; certainly not by as much as doubling or quadrupling its colour-depth would require.

Using a 256-optimised-colour sprite would therefore be an excellent compromise: the system overheads (memory and plotting speed) would be barely more than the RISC OS 4 icons, but the extra shades available in the optimised palettes would mean that I could truly take advantage of the new hardware's 16M-colour screen modes.

If the reason for this is not clear, then think about how an image's palette relates to the computer's screen. The palette contains a fixed number of colours (in this case, 256), any of which can theoretically be displayed on the screen; but what if the current screen mode is also only capable of displaying the same number of different colours? The RISC OS 4 icons are designed with a 256-colour palette, but it's exactly the same palette as is used to display the entire screen in a 256-colour desktop mode, so there's a one-to-one relationship between the colours in the icons and the colours that can be displayed in a 256-colour screen mode.

But with my RISC OS 5 icons, each one has its own arbitrary set of 256 colours, relating to the contents of the icon. Those 256 colours are different from the 256 colours that can be displayed on the screen in a 256-colour desktop mode. There will probably be some overlap between the two, but the available screen colours will always be a subset of the colours required by any given icon. Therefore, any colours required for an icon which aren't available in the current screen mode will be approximated by the nearest colour that is available. This usually leads to a 'posterisation' effect; a loss of the subtle shading or colour fidelity within an icon. Figure 1 shows an example.

Figure 1: The top of the three ROM-applications icons is shown as it is supposed to be seen, with the colours contained in its palette shown to its right. The middle of the three icons is plotted using the standard 256-colour desktop palette (again, shown to its right). Superficially the icons look very much the same; the full-colour icon, which can only be viewed correctly in a 16M-colour screen mode, has degraded well into 256 colours. However, closer examination will reveal the shortcomings of the lower icon, such as the fact that the cream folder is slightly yellower than the intended shade, and that some of the most subtle shading has been lost. For interest, the bottom icon shows how the graphic would reduce into the 16-colour desktop palette, shown to its left (though this colour depth is not supported on Iyonix machines).

Exactly the same situation exists in 32K-colour screen modes; it's just a lot less noticeable because there are so many more shades available. But in reality, in order to be certain that all 256 of the shades within any given icon are being displayed correctly, you do need to be in a true-colour screen mode. The icons will look pretty good in any colour depth from 256 colours upwards, but they can only genuinely look their best in 16M colours.

Anyway, the decision to use 256-colour optimised palettes as opposed to 16M-colour icons was proved to be a good one by examination of the resulting optimised palettes: it was relatively rare for any single icon to require all 256 of its possible colours. Most used fewer discrete colours than this, meaning that to create them as 16M-colour icons would have been extremely wasteful.

Evolution of the RISC OS 5 designs As might be expected, many of the new icons went through a few revisions before being finalised, and different approaches were tried for several types of icon before the final appearance was agreed upon. (The column of icons to the right shows a non-exhaustive selection of the new RISC OS 5 file icons at their regular size, arranged in descending order of filetype number.) File icons Perhaps the most important design fundamental to be decided was the basic appearance of file icons. These account for by far the largest number of icons on the system, and permeate all sorts of areas beyond directory displays. They needed, therefore, to have a strong, consistent and clear design which would be appealing and recognisable but not too fussy. Figure 2 shows the evolution of four common filetype icons; these were among the earliest file icons to be drawn. Figure 2: Iconic evolution! One very early idea was to make file icons 'document-shaped' as on other platforms, with the same proportions as a sheet of A-series paper   Here, the standard square shape of RISC OS file icons has been reinstated, with label text printed vertically as in RISC OS 4; but this makes it hard to read and limits the space available for graphics   The final versions of the icons: the text is now horizontal across the bottom, which makes it far easier to read and maximises the space available for the graphical element   One of my earliest ideas was to break away from the tradition of square file icons, as these are actually quite unusual; other platforms tend to use document-shaped icons (with the same proportions as sheets of paper) to represent documents, which is a sensible enough idea in itself. As I had been asked to create icons that would be appealing to users familiar with other mainstream computing platforms, it seemed a reasonable idea to try making this change, and to create a few icons in 'document style'. The upper row of icons in figure 2 shows the results. I had decided from the outset that a banner was needed to identify the type of several icons, as this is a common feature on other platforms which made its way into RISC OS with RISC OS 4, and it seemed best to place the banner at the base. However, the narrow width of the document-shaped icons meant that only a very short word could be accommodated, and I wondered whether it would be necessary to stick to PC-style three-letter identifiers. Even the word 'Basic' looks somewhat cramped. The document-shaped approach to filetype icons did permit the rather fun effect of having graphical elements extending outside the icon's document element, such as the pen and its shadow in the text file icon and the system logo (cogwheel) overlay in the Data file. However, taken overall, the reduced width of these icons, the presence of the curled corner, and the space required for the banner and cogwheel overlay in many of the icons, meant that there really wasn't sufficient space left for a graphical element. In other words, this design, though it had its attractions, was a recipe for making cramped, overcrowded icons that were hard to identify. Besides, existing RISC OS users (the initial customers for Iyonix machines) would be very used to square file icons, and may not take kindly to this change. Also, making this change could have a profound impact on the appearance and behaviour of existing software. All things considered, it was worth a try but was 'a step too far', and didn't work well for RISC OS, even though it's common elsewhere. The next significant step, shown in the middle row of figure 2, was to use file icons in the same basic style as RISC OS 4. They would be square, they would have the corner-curl at the bottom right, the OS logo (if present) would be at the top-right, and the banner text (if present) would be placed vertically down the left. I actually rather liked this style, but it did still have some problems. Although the banners looked quite stylish with their vertical text, this has always been one of the aspects of the RISC OS 4 icons that I've never liked: vertical text is just inherently a lot more difficult to read (certainly at a glance) than horizontal text. Aside from that, certain elements still got in the way of allowing the icons to be clear and distinctive. The banner text, which is present in the majority of icons, took a lot of space away from the area in which graphics could be created, at the opposite side of the icon from the curled corner. This left a vertical area for the graphics which was similar in shape to the previous set of paper-shaped icons, and if a cogwheel overlay was required (as in the Data icon), there would be precious little room left for the graphical element. Things could, again, easily end up appearing very cluttered (as they do in the Data icon, which is badly overcrowded). So the solution seemed to be to retain most of the elements in the square icon but move the banner to the base and arrange the text horizontally, as shown in the bottom row of figure 2 (the final designs for these icons). This left slightly less room for the text than in its vertical orientation (see the Module file icon, in which the 'e' has been hidden by the corner-curl), but it removed the legibility problem and also left much more space for the graphical part of the icon even if the cogwheel overlay needed to be present; see the Data icon, which now looks very much clearer. So, this final revision seemed to work well by maximising the clarity of the text and the space available for graphics whilst retaining a very similar overall format to the RISC OS 4 icon set. I was also very keen, in all my designs, to aim for realism, even though the icons would be drawn from scratch rather than being based on photographs or other pre-existing elements. (A handful do incorporate photographic elements, but that's very rare.) So a few blotchy pixels to represent text in the text-file icon wouldn't satisfy me; I wanted the text to really be text, even if you couldn't actually read it. (In fact, if you look closely, you can just about read the text in the standard-size text-file icon, even if it is exceedingly tiny; this is thanks to the exceptional quality of text rendering under RISC OS.) So most of my text-based filetypes (not just the text file shown in figure 2) actually use a repeating text string of "The quick brown fox jumps over a lazy dog" as their backdrop. (As an aside, if you think that the text file icons on the middle and bottom rows of figure 2 are the same, look again: the background text in the lower, final icon is slightly darker.) In conjunction with this element of realism, I wanted my shadows to be as realistic as possible. They should darken whatever lay beneath them, and if they were long shadows, such as the one cast by the pen in the text-file icon, they should diffuse appropriately, with the dark central part tapering towards a point and the fuzzy edges diverging away from it; this effect should be very subtle but discernible nevertheless. In a similar vein, I wanted my curled corners to really look as though they were curled, not just drawn on (as in the crude RISC OS 4 versions). This meant that they should not only be drawn realistically, but they should cast a proper shadow, darkening the pixels close by. In fact, I felt that the effect worked better in the earlier prototype icon designs than in the final icons, because in those earlier designs the curls fell over graphical elements whereas, in the final icons, the curls usually appeared over a plain-colour banner. There was therefore less of a visible darkening effect. Still, it was a very trivial point, and the curls clearly do darken the banner colour beneath them. As for the designs, it should be clear in figure 2 that some of the icons are heavily influenced by their earlier RISC OS 3 incarnations. If their layout and format has been influenced by RISC OS 4, it's RISC OS 3 that has most influenced their actual content. The lineage of the text-file and Basic-file icons, for instance, should be obvious. This was a deliberate decision, and was taken partly to comply with Castle's requirement to make things familiar for existing RISC OS users. But I thought it was a sensible decision anyway, in cases where the old icons were perfectly good designs which the RISC OS 4 replacements had not particularly improved upon (which seemed particularly true of the text and Basic file icons). Of course, some icons (particularly ones that had seemed uninspiring at best in earlier days) were redesigned from scratch. The Data file, therefore, now uses a block of binary 0s and 1s as its graphical element, whilst the Module icon uses four interlocking RISC OS cogwheels, playing on that logo's depiction of components plugging together; an ideal connotation for this purpose. I had also been asked explicitly by Castle to make the Basic icon be similar to the old one from RISC OS 3. The Basic file in RISC OS 4 is just a pale blue square, like many other 'system' files (Data, Obey, Absolute and so on), and thus was very hard to distinguish. But looking inside applications, it's very unhelpful just to see a lot of almost identical pale blue squares; it's far better to be able to identify the standard components quickly by visual cues as well as textual filenames. So, for instance, the !RunImage file will usually be either an Absolute or a Basic filetype, and it's helpful to be able to see that at a glance. And it's particularly useful to be able to identify Basic files quickly because (unlike Absolute files) they're directly editable. So, even though it can be viewed as a 'system' file (and hence has a green banner), the Basic icon uses a pseudo-listing in white text on a blue background. (Historically, this actually refers back to Acorn's old Basic editor software, which used that colour scheme by default, though the utility itself hasn't been supplied for a long time and is now largely forgotten.) Directories From the outset, the decision was taken to revert to the old blue colour for folder icons. Aside from the fact that the change to green in RISC OS 4 was a late decision (the preview set of icons for Acorn's Risc PC 2 included blue folders), and one that quite a few people seemed not to like, I had already decided that 'system' files (which accounted for a lot of icons) would be green to match the cogwheel logo. To have green folders as well would be too much emphasis on one colour. Besides, I just preferred blue folders, finding them more restful on the eye, and I felt that blue folders were better able to degrade well into other colour depths. Probably more contentious was the decision to angle the folder icons into 3D. This is the direction in which other platforms have gone, and therefore is a sensible piece of modernisation, but RISC OS has always used straight-on flat folder icons in the past, and I was afraid that the 3D folders might not go down well. Also, of course, the 3D ones were harder to draw, particularly in the cases where they needed to have symbols overlaid on them (such as the Boot, System and Scrap application directories). I therefore created both flat (old-style) and angled folders; they're both illustrated in figure 3. The 3D versions were chosen in the end, partly because the angled effect made them very obviously distinct from normal file icons, and in fact there was far less resistance to this change than I had anticipated; most people seemed to like the idea. Figure 3: The upper two icons show how the folders might have looked if a 'straight-on' view, as in earlier versions of RISC OS, had been adopted; instead, the lower two angled-3D icons were chosen as being more modern-looking and easier to distinguish at a glance from file icons   A late decision with regard to folders was, I believe, a good one: to coordinate their colour scheme with the 'device' idea relating to cream-coloured icons in general. Many resource-style applications take the form of 'folders'; System, Scrap, Boot and Fonts are obvious examples, but others include the Apps folder, and third party applications like SparkFS, which appear as 'devices' on the left-hand side of the icon bar. These are not directories in the traditional sense, and most don't behave like them. For instance, the Apps icon on the icon bar is not a folder in the normal sense, and it ought to be coloured cream because it's device-related and appears on the left of the icon bar. But it's a folder because it contains resources, and it does open a directory display when you single-click on it. However, when you double-click on Boot, System and so on, either nothing visible happens (System sets up paths) or an application is run (Boot runs Configure). Why should these folders be coloured blue like normal directories? They behave completely differently. So a decision was taken that folders should only be coloured blue if they actually open up a filer window when double-clicked. They may perhaps do something else as well (setting up paths or whatever), but if they open a directory display, they should be considered to be behaving like normal folders and should thus be coloured blue. On the other hand, if a folder-shaped application fails to open a directory display when double-clicked, it isn't really behaving like a folder at all. It may cause an application to run, and/or it may set up system variables and paths, but if it doesn't open a directory display then it isn't behaving like a folder. So 'resource' applications of this kind, and folders which relate to hardware or the system (and perhaps appear on the left-hand side of the icon bar), should be coloured cream. This idea was apparently mooted for RISC OS 4 (at least inasmuch as the Boot folder was coloured differently than other directories, though the icon bar's Apps icon was a different colour again), but was dropped before release. I believe that to formalise it, though, was a good move: it gives users a clear visual clue as to what is likely to happen if they double-click on a folder-like application icon. Figure 4 gives a good example of the distinction. Figure 4: Replay's ARMovie and ARWork resources use the same basic icon; but ARMovie apparently does nothing when double-clicked (it sets up variables and so on), whereas ARWork, being blue, opens up to reveal its contents   Icon families As stated previously, it was felt to be a very good idea to relate similar icons together with a family resemblance, whilst allowing each one to be clearly individual in its own right. The following figures provide examples of how this was tackled for a few different types of icon. In most cases (though not all), each broad type would have a 'parent' type and then a series of subsidiary family members. The parent filetype would be the one most closely associated with a RISC OS editor, and would be a full-icon graphic featuring an element from the editor application's graphic. The subsidiary types would have banners to identify them and would share a common colour scheme and graphical elements from the parent icon, but would not feature the element from the editor application, because that application may not be associated with them directly. The concept is perhaps best demonstrated by the bitmap files, as shown in figure 5. The basic bitmap editor that's central to RISC OS is Paint, which features a red paintbrush graphic. So the main filetype associated with Paint, the sprite file, also features that paintbrush, but in the act of 'painting a photograph' (i.e. a bitmap graphic). The image being painted, though, has been broken up by a square grid, to indicate the pixel-based nature of the file's contents. That 'bitmap grid' is an important concept, and the graphical element that's carried through to all the subsidiary bitmap file icons; they also have a red banner to associate them with the red brush from Paint. However, because there are so very many types of bitmap file, and only very few which are associated with Paint itself (sprites and JPEGs), it's important that they should be easy to distinguish from one another and not associated too closely with Paint. So, the only common elements they share are a red banner, a pink file background (in icons where it's visible at all) and the 'bitmap grid' effect. The grid is so arranged that it appears strong at the right-hand edge of the icon but fades away towards the left, and the main graphical focus is generally at the left, not being interfered with too much by the grid. Figure 5: Bitmap family icons, comprising the editor icon (Paint), the parent filetype (sprite file) and a couple of subsidiary icons of decreasing relevance to the editor (JPEG and PhotoCD)   Figure 6 shows members of the vector family. By contrast with bitmap graphics, there are relatively few vector types that are supported by RISC OS (directly at least), and there are also several vector-based filetypes which don't really come into quite the same class of 'user-created graphics' that one thinks of in relation to Draw files. For instance, PostScript files are vector-based in just the same way as Draw files (vector files which can contain bitmaps and text), but they are more associated with printers and DTP packages. Fonts, too, are vector-based, but are also considered in a different class. So, the vector family is rather disjunct. The green Draw pencil is reproduced in the main Draw filetype, which is very reminiscent of its old RISC OS 2/3 version, with three coloured shapes in the background. The same shapes, without the pencil, are also used for the DXF file, which has a banner and can be loaded by Draw. PostScript files, being 'primary' filetypes but also in the same class as Draw files, include the three background shapes, but rendered in monochrome (as a lot of PostScript printing is done to monochrome printers). The PostScript file features a large engraved P in the foreground to make the font connection clear. In fact, the RISC OS outline font filetype, which is vaguely related to both vectors and printing, uses a large engraved F in order to provide some vague consistency, though the relationship is intentionally tentative. Figure 6: Vector family icons, comprising the editor icon (Draw), the parent filetype (Draw file), a subsidiary icon (DXF) and a related primary-level icon (PostScript)   The text file family (see figure 7) is both extensive and widely defined. The basic editor is of course Edit, and the main filetype the plain text file, but subsidiary files can encompass a huge range of types. There are, after all, many text-based files for script languages and so on, as well as word-processor and DTP documents, and one has to draw the line somewhere. I took the view that common text-based and word processor filetypes, particularly cross-platform ones without a native editor (like Microsoft Word documents), should be members of the text family and have blue banners to match the Edit pen (which also features in the Writer+ application icon). Other text-based documents are clearly things like TeX files and CSV (Comma-Separated Value) files. HTML files could arguably be included directly in the text family, because clearly they are text-based (as indeed are PostScript files); but there are several HTML variants (XML etc.), and these files are associated more with Web browsers and specific editors, so they form their own family. Nevertheless, they maintain ties with text files by having a text-based background based on real, legible text. Figure 7: Text family icons have a blue banner and white paper background, and encompass plain text files, styled documents, script language files, word processor documents and other human-editable data files   Audio files were given a colour scheme of a parchment-coloured background (like much printed music) and an orange banner (see figure 8), and encompass music files, sound samples and sound-generator files. The basic music editor supplied with RISC OS is Maestro. The use of the word Maestro in the program and main file icon is unusual, but is a play on the musical direction 'Maestoso', which would appear in roughly this position if it were used as a musical tempo direction. The music sample used in these icons is in fact a properly-typeset fragment of music, using my own PMS musical outline font. The Maestro file is one example where the application icon itself is used within its primary filetype with no significant modification. I did consider the use of a conductor's baton in the application icon, to match the 'implements' in Draw, Edit and Paint, but the idea wasn't worth pursuing because batons are not very distinctive objects and should in any case be used the 'wrong way up' for this context (the handle would need to be at the bottom-left). In this family of icons, actual music files (such as MIDI) use the music fragment along with the banner, but other audio files are also included. 'Emission' file icons (sound-generating voice modules) use a speaker icon with sound waves coming out of it; 'reception' file icons (sound samples) use an ear with sound-waves going into it. In most of these icons, the waves are set against a graph background using five orange lines, reflecting the five lines of a stave, but an exception is made for the Datavox filetype (shown in figure 8) in order to use a 1s and 0s backdrop from the Data filetype instead. Figure 8: Audio family icons   Finally, figure 9 shows members of the video family. These are all very closely related indeed, and the main filetype in the set breaks the normal 'parent' rule by having a banner. That's mainly because of its special nature: no general-purpose editor is supplied for Replay films; they're associated with a player (few people actually build Replay movies) and Replay files are intended as a video exchange format (with the single filetype icon covering many sub-types). It seemed more important to give all movie filetypes a similar appearance in which the main distinction was the combination of colours used. In fact, there's a subtle allusion to RISC OS 4 here, in that the colours chosen reflect the ones used in the equivalent files from the RISC OS 4 icon set. Figure 9: Video family icons   There are of course other filetype families, and individual programs will introduce their own sets of related files and colour schemes. The examples above are just instances of the more common generic classifications. All filetype icons also, of course, require a 'small' variant for use in small-icon and full-info displays, menus and so on. Because of their slightly different proportions, all of these had to be defined separately. However, in most cases, the small icon just uses a scaled version of the graphical element from the main icon, or an unscaled but simplified version of it. Banners are discarded from small icons because they would be too minuscule to be useful.

Device icons

Figure 10: The RAM disc icon needed to look like a RAM chip; it would not have been appropriate to try to apply a cream colour to the icon, even though it is a 'device'

So in the first instance we opted for realistic images of the media used by the device in question, rather than necessarily going for a cream-coloured device icon for storage devices.

The first disc icon to be drawn was for the floppy drive, and initially it was a solid blue colour. In fact, in an attempt to add an extra degree of realism, simulated moulding-marks were added to the plastic. It's a very subtle effect, but you can just see them if you look closely at the first icon in figure 11: concentric circles showing where the disc is held in the square plastic case. This isn't fanciful: you can see exactly the same effect with real floppies.

Blue was chosen as being a common, pleasant and sombre colour from the standard Wimp palette, which is often used for real floppy discs. However, the big blue square was a bit too attention-grabbing on the icon bar, so a cream-coloured label was added, both to reduce the amount of stark blue and to tie in with the device colour. The initial release of the Iyonix had a green cogwheel logo on the label, but this was subsequently dropped in favour of keeping the label clean. The label hides the 'moulding' effect, but that was barely visible anyway! Figure 11 shows the three versions of the icon.

Figure 11: The floppy disc icon started off blank, but a cream 'device colour' label was subsequently added

The CD drive icon can show three states: one for normal CDs (also used when there's no CD in the drive) and two special icons for use when audio CDs or Kodak PhotoCDs are inserted. Commercially-pressed CDs (both data and audio) are usually silver, so I wanted to go for realism rather than using the device-cream colour. Achieving a realistic-looking and subtle rainbow effect proved to be a tough job (the CD icon was the most time-consuming single icon to create), not least because I wanted the icon to degrade well into shades of pale grey in 256-colour modes (in order to look 'silver' when the very subtle colours weren't available). By contrast with normal CDs, PhotoCDs are golden in colour, so I applied a colour-shift to change the icon's shade when a PhotoCD is inserted in the drive; again, this needed to degrade to appropriate shades of gold in 256-colour modes. Both audio CD and PhotoCD icons also have symbolic overlays to show what kind of CD is in the drive, weighted to the left of the icon because these icons appear on the left-hand side of the icon bar. Figure 12 shows these three icons.

Figure 12: CD, audio CD and PhotoCD icons; these feature very subtle rainbow colours which degrade into shades of plain 'silver' and 'gold' in 256-colour modes

The troublesome hard disc

So initially we began with a 'tall box' icon representing 'the computer', as on RISC OS 4. I was actually pretty unhappy with this icon; I didn't feel that I'd drawn it at all well, and it really didn't work as a graphic. But aside from that, it didn't work as a concept either. If a user has installed a second hard drive, there will be two 'computer' icons on the icon bar. That's inappropriate and confusing (there's only one computer, after all), and also leads to a potential conflict with network icons. I tried to get away from the network icon confusion by creating a 3D version of the icon, but didn't like that either; see figure 13.

Figure 13: Unsuccessful attempts at representing the hard drive icon as the computer

So my first 'serious' attempt at a hard drive icon was to draw a stylised image of an open hard disc drive, showing the disc itself, a read/write head and some suggestion of the other gadgetry. Initially I drew this in portrait format, but it was criticised for looking too much like a door bell (fair comment, actually!), so I put it into landscape format, which gave more room for the disc name below it. This icon was seen on pre-release machines, and had a matching Discs icon for Acorn Access with two drives overlapping (see figure 14).

Figure 14: The detailed pre-release hard disc icon in 'door bell' format, landscape format and adapted for use as the Acorn Access Discs icon

Personally I liked that hard drive icon a lot. However, it was felt in some quarters that it was too detailed and fiddly, and that it was also too obscure an image, in that many users wouldn't know what an open hard drive looked like. But I felt that the most valid criticism was that it was too specific an image: it was a very obvious representation of a hard drive and nothing else; whereas a hard drive icon might theoretically be needed to represent something that isn't actually a hard drive (maybe a USB digital camera or some other kind of external storage device). It was also not a 'realistic' icon in that hard drives are never operated with their lids off; if the lid is off, the drive is, by definition, broken!

So it was back to the drawing board again. I tried to counter the 'too fiddly' argument by doing a stylised version with just discs and read/write heads but none of the rest of the mechanism; but that didn't work at all in itself, and also looked far too much like the CD icon. I tried to counter the 'open hard drive' problem with a closed-case version (and remember that Windows XP and Mac OS X both use 'closed hard drive' icons to represent their disc drives), but that icon looked awful; I didn't like it at all. Figure 15, included with some embarrassment on my part, shows these two awful icons, which were never taken remotely seriously!

Figure 15: Two really dreadful hard drive 'concept icons' that were scrapped as soon as they were drawn!

All things considered, the best option seemed to be to go back to the old 'cream box' idea from RISC OS 2/3 days to represent a 'generic storage device' rather than a specific style of unit. But this was such a boring idea that I felt compelled to try to create at least a vaguely interesting graphic. My first attempt, therefore, was rectangular with curved vertical sides. I quite liked it, but its big problem was that it looked like an external device, whereas it needed to be used for an internal one. So away went the curved sides, and I ended up with a rectangular icon that featured the same proportions as a 5¼" drive; see figure 16.

Figure 16: An 'external drive' icon, and the final rectangular version of the hard disc icon, together with the final Acorn Access Discs icon which was based upon it

(In fact, the curved-sided icon subsequently found a use on the Iyonix 32-bit software database at http://www.iyonix.com/software/ as an icon representing generic external peripherals.)

The final rectangular icon may have been a pretty boring design to end up with, but it did have some practical advantages. It was of sufficiently indeterminate nature that it could be interpreted as either an internal or an external device; it looked like 'a disc drive' but not one of any particular type; and the fact that it was so plain meant that it could work well with the other bits and pieces that needed to be added to it to make 'network drive' icons and so on. In fact, the Acorn Access Discs icon could be made of two of the hard disc icons stacked one on top of the other, which was a concept that worked well, and because the drive icon was projected into 3D, the angle of the top of the Access Discs icon could be adapted to match the viewing perspective of the hard drive icon (i.e. you see less of the top because it's closer to the perceived eye-level).

So I have to admit that the hard drive is certainly one of the less inspiring RISC OS 5 icons, but at least it's appropriate for the job. And I don't think I was alone in finding this an awkward concept to represent, as the hard drive icons in Windows XP and Mac OS X seem to be among the least successful icons on those platforms, too.

Printers

It was also helpful to be able to adapt and combine icons for different states. All printer icons need 'active', 'inactive' and 'error' icons, and these were represented by having cream-coloured printers with paper in them for the 'active' state and grey printers without paper for the 'inactive' state. The 'error' state was the same as the inactive state, but with an error-triangle symbol superimposed in the top-left corner. Some printer icons could also be quite similar and make use of other elements: the PDF printer driver, for instance, is the same as the PostScript printer driver icon with the small PDF filetype icon superimposed on it. Figure 17 shows a selection of printer icons in various states.

Figure 17: Dot-matrix, PostScript and PDF printer driver icons in 'active', 'inactive' and 'error' states

Error symbols

Originally, RISC OS just had an 'exclamation mark in triangle' icon to represent errors; Acorn added several other variations with the introduction of enhanced error boxes in RISC OS 3.5. 'Question' and 'information' symbols were added, as were 'warning' (as opposed to 'error') and a couple of user-error graphics which are rarely (if ever!) seen.

The problem was that these symbols were not very distinctive. The 'information' graphic was fine, because it was a dark blue circle with a white 'information-i' inside it, but the warning and error symbols were identical, and the user errors were almost the same (except that they lacked any symbol inside the triangle). Perhaps worst of all, the 'question' graphic took the form of an error triangle. Not only did this convey the wrong message (a question is not an error!), but it looked ugly because the broad top part of the question-mark symbol was in the narrowest part of the parent triangle (at the apex).

I wanted to refine these symbols for RISC OS 5, so as well as drawing them in more faithful proportion to genuine road signs, I decided to reserve the 'error triangle' shape for genuine errors. So there is now a distinction between round shapes for informational messages and triangular shapes for more serious errors (culminating in the octagonal STOP sign for catastrophes!): figure 18 shows the symbols in ascending order of seriousness.

Figure 18: Informational and error symbols in increasing seriousness: Information, Question, Warning, User error, Error, Program error

As for other general-purpose elements, some of the most important graphics that needed to be designed were the new window border tools (and associated in-window gadgets) and window background textures.

Window textures

For RISC OS 5 I wanted to create a texture that was both sophisticated but unobtrusive; one that would be visible but not distracting and whose repetition would not be obvious. Above all, it should not distract the eye in the way that I felt the RISC OS 4 texture did. So what kind of texture ought I to create? I decided that I should move away from a marble-inspired texture to one reminiscent of paper. After all, we read printed words from fibrous paper books, so why not translate that concept to the screen?

Finding the right balance when creating a 'paper' texture was quite difficult; it was all too easy to include distracting little pips or undulations in an otherwise smooth texture, or not to get the overall lightness quite right to match the Wimp's grey-1 colour. But eventually I achieved what I intended and was pleased with the result: a restful 'paper' texture that, at a glance, gave the impression of plain grey, and with a pattern that was so subtle that spotting its repeats was very hard to do.

The only problem was that I had created a monochrome texture, and this somehow made the screen look very 'cold'. So to give an almost imperceptible 'warmth' to the screen I added a tiny amount of colour noise into the texture, so that it was no longer composed of greys but of very pale shades of colour. The difference was almost impossible to see in itself, but it made the whole screen feel warmer and less sterile. It's a bit like viewing an old black and white film on a colour TV set as opposed to watching the same thing on a black and white TV; the two ought to look the same, but the colour TV will actually give warmer-looking pictures because it's using colour to simulate monochrome. Figure 19 shows both versions of the texture; can you tell them apart?

Figure 19: The window background texture in its monochrome (left) and 'colour' (right) variants; if you can't spot the difference, try using a magnifying glass utility to view them closely

Once the basic tile was designed, I produced variants of it for use in other colour depths, and then based some other textures on it. The menu texture is exactly the same tile, but significantly lightened up so that it's almost white (I wanted there to be more difference between the shades of window and menu background textures than there is in RISC OS 4). I also made darker versions to form the basis of a few new Pinboard tiles.

Window tools

But I very much wanted to get away from the Acorn New Look tools, for various reasons. In fact, I had never liked New Look all that much. Although I did like some of the ideas the tools introduced (particularly the textured scroll bars and sliders with grooves), there were lots of things I didn't like at all. For instance, it's always annoyed me that the tools move downwards and to the right when pressed, rather than pushing inwards, which is what all other icons on the RISC OS desktop do. I didn't like the fact that they lit up in bright yellow when clicked, because there's no reason for them to do so (the tool symbols are etched into the tools; they're not lights), and again, other button icons on the RISC OS desktop go grey (or orange in older software) when pressed, not yellow. I disliked the fact that the title bar was the only tool to go cream when a window gained input focus, and I didn't see why the title bar gave no feedback when clicked (except that the down-right pressing motion wouldn't work well in that context). There were other design characteristics that I disliked, too, such as the hard black border around scroll bar sliders, and the fact that the symbols in the Back and Close tools, which are adjacent, don't balance well with each other.

So I was keen to do away with the old New Look tools and address the problems I've listed (and others). But there were practical difficulties in creating new designs, and strong opposition to any significant visual change even though a 'new look' is what I was supposed to be creating. The best compromise, therefore, seemed to be to redraw the New Look tools, in effect, making appropriate changes which would address the things that I disliked about the originals whilst hopefully keeping the positive aspects.

My new tools therefore look superficially very similar indeed to the previous set. However, they're quite a lot more subtle. The texturing that I applied to the tools is, again, a version of the 'paper' texture that I used for window and menu backgrounds, so there's strong design unity here. The texturing is also a lot more subtle: the old Acorn New Look tools were 16-colour icons with textures that use only a couple of shades of grey; my new tools are 256-colour ones which use at least twice as many shades to give a smoother, subtler textured effect. This can be seen particularly well in the scroll bars and sliders, which now have far more refined shading and texturing than they did before, and I got rid of the unnecessary and ugly black border surrounding the scroll-slider.

All my tools now turn cream when the window gains input focus, and they all darken and push inwards when pressed (which was achieved by using a pattern of grey and masked pixels); even the title bar presses inwards, which may come as a bit of a shock to people who have been using New Look for years, but it's a helpful visual cue.

I did take the opportunity to modify some of the tool legends. I didn't like the Iconise tool in New Look because it was just a narrow 'slit' which conveyed nothing (and it didn't match the engraved style of other tools, either). This narrow rectangle implied either a 'collapse to title bar' (as can happen on the Mac) or 'collapse to taskbar button' (which happens on Windows) function; but what it did not imply was a 'pin' operation, which is what actually happens under RISC OS. Pins have round heads, and pinned windows are denoted by window-shaped icons with round pins sticking out of them; so it seemed obvious to me that the Iconise tool ought also to feature a round 'pin-like' symbol. And no matter which way you look at it, it's no less meaningful a symbol than a narrow slit!

I also didn't much care for the Toggle-size icon in New Look; it was just a square that toggled between two sizes. Whilst its meaning is clear enough, I've always found the squares hard to distinguish at a glance because they're so similar. I therefore replaced the squares with a pair of triangular arrows (matching the style of the scroll-arrows) to indicate whether a window would expand outwards or collapse inwards.

Actually, I wanted to change the symbols in the Back and Size icons, too, to make them simple primary shapes, like all my other tools; they would have become northwest- and southeast-facing arrows respectively, to match the Toggle tool. However, this idea didn't find favour and I ended up drawing symbols that were similar to the ones that everyone was used to.

So overall the window tools incorporated a number of compromises, and maybe nobody got exactly what they wanted with them, but even so I'm convinced that they're a big improvement on the previous New Look set. Figure 20 shows the old and new styles side by side.

Figure 20: The old Acorn New Look tools (left) and the new RISC OS 5 replacements (right)

In figure 20, notice how poorly balanced the tools on either side of the title bar are in the old New Look set: they're very different sizes, and hence look quite haphazard. Some of the symbols (the Back tool and arrows) also look too big because they crowd against the edges. Note also that some of the tools (Back, Close, Toggle, Size) are 'etched' whereas the others (Iconise and the arrows) are sunk in. In the RISC OS 5 tools, the symbols have more 'breathing space' around them and also share the same bounding box, leading to a much better balanced appearance. And finally, they all use a consistent sunk-in style rather than New Look's haphazard mixture of sunk-in and engraved.

Postlude: user reactions

Anyway, it's all personal opinion, and the 'textured versus untextured' argument is almost a comment on people's reactions to the entire new design: one has to take the rough with the smooth!

What I have observed throughout the design process is that many people are simply opposed to change of any kind, no matter what form it takes. A user interface is something with which people become very familiar and attached, and any change from what they're accustomed to is met with resistance, even if the change is positive. It's my belief that if people give the new RISC OS 5 look a chance, and spend some time with it, they'll come to appreciate and like it.

I've received quite a lot of feedback about the new icons already (much of which arrived during the design process), and, speaking very broadly, opinion was largely divided into the following points of view:

• RISC OS is badly in need of a greatly improved set of user interface icons which can stand up against, and look impressive alongside, icons in modern operating systems such as Windows XP and Mac OS X.
• The appearance of the OS is totally unimportant. The icons we've got already are perfectly adequate, and designing a new set is a completely pointless waste of time and resources.
• We should scrap the RISC OS 4 icons because they don't look very good, a lot of them are virtually indistinguishable and they got rid of many good ideas that were present in the old RISC OS 3 icons.
• We should keep the RISC OS 4 icons because they're really nice, everybody likes them or has got used to them now, and it's pointless to have yet another new set.
• We should keep as many visual cues as possible from earlier operating systems in order to retain a lot of the existing RISC OS 'look and feel', not make existing applications look too different, and help users of the new system to feel at home right away.
• We should totally discard all existing concepts and design something absolutely new, to look as modern as possible and take advantage of the Iyonix' much-improved video hardware.
• We should opt for extremely simplistic 'cartoon' icons like those in RISC OS 2 for maximum ease of at-a-glance recognition.
• We should go for genuinely photo-realistic icons which look exactly like the objects that they're supposed to represent, as this is the direction in which modern operating systems are now going (especially Mac OS X, which is widely acknowledged as having the nicest user interface currently in existence).
• The new RISC OS 5 icons look superb. They're distinctive, look very polished and professional, and are much better than anything we've seen on RISC OS before.
• Any fool can see that the new RISC OS 5 icons are complete rubbish. They may look 'pretty' but they totally ignore all the principles of good user interface design and just end up confusing the user.

These are all genuine views that were expressed to me by various people, and they lead to one inescapable conclusion: it's impossible to please everyone. A percentage of users will passionately loathe the icons no matter what they look like, whilst others will be more fair minded; some may even like them!

In the end, there seemed to be only one possible course of action, which was to steer a middle course and attempt to find a well-balanced compromise between the various diametrically opposed viewpoints. My own opinion about the approach we should take with the icons largely coincided with what Castle actually wanted, and can be summarised as follows:

• This major new release of RISC OS really did need a new, improved look. Other operating systems are moving towards a photo-realistic appearance with nice shadows and anti-aliasing, and we shouldn't be left behind with a crude-looking system.
• The new look should make good use of colour and stand up well against modern rivals, but not be so radical as to be totally unfamiliar to existing users of the platform. In other words, we needed a modernisation of the best aspects of RISC OS icons from the past, rather than a radically different approach. We needed to aim for an appearance in which the icons are colourful but not garish; realistic-looking if not quite photographic; easy to distinguish from one another; well-coordinated and consistent with one another.

It's my belief that those aims have been achieved, and that the new RISC OS 5 appearance is a success. Obviously I would say that, given that I'm the designer; the new look is by definition to my own taste! Nevertheless, I think that the facts and considerations behind the designs, some of which I've tried to put across in this article, back up the conclusion. It's true that in some ways I wanted to be more radical with the new design, and I felt from time to time that good ideas were in danger of being sacrificed for the sake of maintaining consistency with things that were a decade or more old. But it was all a matter of attempting to find an appropriate compromise between being radically different and staying exactly the same. In the new designs I feel that we generally erred on the side of caution, but I'm still satisfied that what we've ended up with is both successful and a lot better than what existed before.

People in general are inherently conservative, and a period of adjustment to (and possibly reaction against) the new-look RISC OS is only natural. But it's my hope and belief that anyone who spends time with the new look will gradually become accustomed to it and appreciate it more. A few people have been good enough to say that, after an initially sceptical reaction, they've begun to like the new look more and more as they've continued to use it. I hope that this proves to be the case with the majority of users. It's easy to create a gimmicky set of icons that initially seem spectacular but which quickly become wearisome, and my hope with the RISC OS 5 set was that I could avoid that trap and produce something that people would actually want to live with. I hope that I've achieved my aims, but only time will tell. All I can say is that, from my own point of view, having used the icons for longer than anyone else, I'm very happy with them, and the previous icons from earlier versions of RISC OS now seem very crude by comparison! I just hope that other users come to feel the same way.

Footnote

Icon design service