GUIdebook: Graphical User Interface galleryHome > Articles > “Apple II User Interfaces”
Go backArticlesApple II user interfaces

Some notes about the various presentations of Apple II User Interfaces

Written by and © Tony Kavadias in June 2004. Can be distributed with permission from the author only.

An Apple IIc computer running AppleWorks
This image can be zoomedAn Apple IIc computer running AppleWorks
This paper documents some of the most interesting aspects of Apple II user interfaces. Included are both graphical and text-based interfaces that have noticeably been made under various contexts and stages of development on the Apple IIe/IIc by both Apple Computer and third party developers, whilst showing the standardized user interface of the Apple IIGS, which heavily borrows from the classic Macintosh.

Regrettably, GEOS and Apple II Pascal are not included in this presentation. GEOS proved to be difficult to run adequately due to configuration problems, and Apple II Pascal is simply absent from my software library. I hope you enjoy these nostalgic screenshots, along with the commentary alongside them illustrating why these interfaces are important to note.

Text-based user interfaces of the Apple II

Back in the days when there was no room for graphical user interfaces in a personal computer, people wrote programs using a text display (what else was there?!). But regardless of what display mode was used to present information, the information was indeed presented in some kind of stylistic fashion. Early Apple II system software programs exhibited this trait in the apparent design of the computer software with the intent that the software was less intimidating and easier to understand for the user. To explain why this was the case, it had to be realised that DOS 3.2 was the first Disk Operating System for the Disk II floppy disk drive – prior to that was the cassette interface and the Integer BASIC command-line prompt!

Whether the specifics of the user interface design were intentional or just simply because of one product manager’s ideas of how (s)he wanted Apple II system software programs to look, the early DOS System Master and the ProDOS User’s Disk tools for the Apple II Plus and first-generation 64K Apple IIe did have a distinctive “look and feel” about them, even though you could argue that the design was minimalist, bordering on uninspiring. These system programs had two things in common where user interface design was concerned: they produced a menu that was single-key activated, and they produced a banner identifying the program in use or the current location in the menu hierarchy.

The DOS 3.2 System Master’s File Developer program (affectionately known as FID) was probably where this so-called Apple II user interface style started. You can see in the following screen shots the distinctive asterisk-style boxes reminiscent of how Assembly and C programmers write comments in their source code, and the full-screen menus. No other kinds of programs adopted this style; only Apple system programs that managed computer files and disks did.

Apple II File Developer
This image can be zoomedApple II File Developer
ProDOS User’s Disk
This image can be zoomedProDOS User’s Disk
ProDOS System Utilities
This image can be zoomedProDOS System Utilities

The design was implemented so that the banner was always present indicating where you were in a program, while the content region was pretty much unstructured with content as the program saw fit to display. Even as ProDOS became the new operating system standard for the Apple II, the use of asterisks and uppercase text in its design was probably just the consequence of accommodating ProDOS on the Apple II Plus, which did not have lowercase text or an 80-column text display. It continued throughout most of ProDOS 1.0's life span until the Apple II Plus was no longer supported with the release of ProDOS version 1.2.

One system program that did run on the Apple II Plus and offered a more stylish (yet simplistic) design was the ProDOS Conversion Kit. You will see the significance of this interface later in this article.

ProDOS Conversion Kit
This image can be zoomedProDOS Conversion Kit

On an Apple II Plus, the program was smart enough to use all-uppercase text for its display. The asterisks were replaced with minus characters, which reduced the on-screen clutter and busyness of the asterisk character. The display was partitioned into three sections... the header, the body (or content), and the footer. The design intent of the user interface became apparent when the Apple II drew to its display, because the content region actually scrolled to fit more text whilst the header and footer regions remained static and preserved regardless of the results of an operation.

On the departure of the Apple II Plus, and with the introduction of the Apple IIc and Enhanced Apple IIe, which supported 80-column text, 128K of memory as standard, and an extension to the Apple II’s ASCII character set called MouseText, versions of the Apple II system software with a more formal appearance started using more stylish and functional user interface designs, using more arrow keys and highlighting and less single-key menus. However, with the realisation that hitting arrow keys could be tedious to the user, it was made so that hitting a letter key on the keyboard would select a command starting with that letter (but not actually invoke it).

Apple IIe System Utilities
This image can be zoomedApple IIe System Utilities

AppleWorks for the Apple IIe and IIc also used MouseText in order to implement its folder-oriented user interface display. It also started showing signs of some of the standard user interface elements seen in today’s graphical user interfaces... particularly the progress bar, seen here as AppleWorks starts up. Admittedly, this appeared at about the same time as the Macintosh, so it was not like the Apple II was used as a user interface prototyping platform for the Macintosh or something! But the fact that the Apple II text display was used to illustrate graphical feedback controls was indeed an interesting aspect of user interface design on an Apple II.

Loading AppleWorks
This image can be zoomedLoading AppleWorks
Main menu of AppleWorks
This image can be zoomedMain menu of AppleWorks
File interface of AppleWorks
This image can be zoomedFile interface of AppleWorks

Interestingly enough, other components of AppleWorks didn’t use MouseText:

AppleWorks database categories
This image can be zoomedAppleWorks database categories
AppleWorks database
This image can be zoomedAppleWorks database

AppleWorks word processor
This image can be zoomedAppleWorks word processor
AppleWorks spreadsheet
This image can be zoomedAppleWorks spreadsheet

suggesting that there was an effort for AppleWorks to remain functional on those Apple IIe computers that didn’t support MouseText (original 64K Apple IIe computers that were upgraded to 128K, but not with the Enhanced Apple IIe ROMs). But again, like the ProDOS Conversion Kit, the three-region text display and user interface style remained as a formal user interface design for text-based Apple II applications from Apple.

AppleWorks became the first text-based user interface to adopt a standard user interface template that was mimicked by other Apple II applications developed by Apple and third parties. The Apple II System Disk for the Apple IIe and IIc also adopted the folder-oriented user interface soon after the release of AppleWorks.

Apple II System Disk 3.2
This image can be zoomedApple II System Disk 3.2

To the Apple II enthusiast like myself, one could notice the absence of MouseText on this display (AppleWorks’ folders look cleaner with completely formed lines, which could only be done with the aid of MouseText). This was probably done again to support the original 64K Apple IIe.

Apple II graphical user interfaces

The first Apple II program to use a mouse and implement some sort of graphical user interface was MousePaint. The program was featured on the Apple II ProDOS User’s Disk, and on a separate disk that came with the Apple IIe Mouse Card.

This image can be zoomedMousePaint
One of MousePaint menus
This image can be zoomedOne of MousePaint menus

MousePaint was an Apple II implementation of the popular Macintosh application MacPaint. MousePaint’s user interface was not as advanced – there were no keyboard shortcuts to menu commands, and the menu commands were rather confusing and difficult to understand at first (it took a while for users to understand what the command “Put a copy in...” actually meant – on the Macintosh, this would be the “Save As...” command). MousePaint was a stand-alone program – it did not support any other software and only relied on the ProDOS operating system for disk operations like opening and saving files. Also, MousePaint only knew how to print to an ImageWriter or to a Scribe printer – no other printers were supported.

If there is one comment to make about MousePaint, it’s that for a graphically intensive Apple II application, even on a 64K Apple IIe (which ran at 1 MHz), the user interface was surprisingly responsive. The mouse was remarkably smooth, and scrolling around the pixel canvas was seemingly effortless. Menus also appeared instantaneously, with no noticable drawing lag. Yet, MousePaint did not have many things to animate – only the menu bar was the most obviously “expensive” user interface component to manage.

There were at least two other Apple II applications that implemented graphical user interfaces. MouseCalc was an application by International Solutions, Inc., which operated the Apple IIe’s Double-High-Resolution graphics mode to implement an 80-column display with built-in embedded spreadsheet graphics. The program used the mouse to operate it, but the interface did not resemble that of a traditional desktop – it was more like a graphically enabled AppleWorks with an on-screen pointer (the display was ugly, mostly black with white text, and resembled that what you’d probably expect to see on an IBM PC).

Another more convincing desktop-like application for the Apple IIe and IIc was BeagleWrite by Beagle Brothers (also known as MultiScribe before Beagle Brothers took the product over), which was a rather sophisticated (for its time) word processing application that actually implemented some of the typical ruler-based formatting features, and built-in desk accessories, although they did not allow BeagleWrite to actually work alongside the accessories like on a Macintosh.

BeagleWrite file open dialog
This image can be zoomedBeagleWrite file open dialog
BeagleWrite File menu
This image can be zoomedBeagleWrite File menu

BeagleWrite’s user interface permitted the use of the keyboard to control the program entirely (no mouse required), but at the cost of not being as intuitive as it could be for both the mouse or the keyboard user. Additionally, notice the keyboard shortcuts... with the distinct lack of user interface guidelines, keyboard shortcuts often did not agree with those of other applications. Keyboard shortcuts were also available for controls that would not otherwise be expected to have one, such as buttons.

The Apple IIe and IIc did not get a graphically oriented system disk, although the 256K Apple IIGS did. MouseDesk was the Apple IIGS’s first desktop shell, and it provided most of what Apple II users would ever want out of a system utility, while showing a glimpse of the future of the Apple IIGS.

This image can be zoomedMouseDesk
MouseDesk File menu
This image can be zoomedMouseDesk File menu
MouseDesk Get Info dialog
This image can be zoomedMouseDesk Get Info dialog

The Apple IIGS was pretty much introduced to potential users in black-and-white. MouseDesk, and the first Tour of the Apple IIGS, were applications that used the Apple II’s Double-High-Resolution graphics mode in black-and-white, and ran under 8-bit 6502 emulation mode! While it was enough to do basic filesystem maintenance and start both ProDOS 8- and ProDOS 16-based programs, it took Apple over a year (and more hardware updates) to release something as a desktop shell that resembled much more of what the Apple IIGS could have been.

MouseDesk’s user interface was rather awkward to use, because of flaws in the user interface implementation. While it looked like Macintosh, it was far from it. Menu commands had shortcuts which one could never guess, and some commands were cryptic and difficult to use, because of the direct use of traditional Apple II idioms like “slot and drive” specifications or “ProDOS block sizes,” or because of simply the poor implementation of user interface controls and behaviours. One thing I noticed about the interface was that it ignored the user’s current selection for some commands, forcing users to re-specify what it was they want a command to act on. Other commands were implemented as separate programs, causing MouseDesk to quit and start another application, resulting in MouseDesk forgetting all about what state it was in when it returned to the user’s desktop after completion of the secondary command. And like some other Apple II programs that appeared to have desk accessories, MouseDesk’s desk accessories overtook the entire desktop, preventing the user to perform other tasks whilst an accessory was open.

MouseDesk Erase a Disk dialog
This image can be zoomedMouseDesk Erase a Disk dialog
MouseDesk Quick Copy dialog
This image can be zoomedMouseDesk Quick Copy dialog
MouseDesk Calculator accessory
This image can be zoomedMouseDesk Calculator accessory

Lastly... MouseDesk’s error messages resembled the countless cryptic messages of various other Apple II applications that have been a legacy of Apple II computing.

Sample MouseDesk error message
This image can be zoomedSample MouseDesk error message

To demonstrate how incomplete MouseDesk was as a system utility...

Apple IIGS System Utilities
This image can be zoomedApple IIGS System Utilities

...this was provided for those special moments when MouseDesk was not up to the task, mostly due to bugs! Doesn’t this look familiar?! This was included on the MouseDesk floppy disk. Notice how this software was renamed “Apple IIGS System Utilities”!

Incidentally, it was possible to get MouseDesk to run on an 128K Apple IIe or IIc, being an 8-bit Apple II program, but it actually took a bit of work to pry MouseDesk off of its 800K floppy disk, because of how MouseDesk was organised as being a shell program for ProDOS 16, and because parts of MouseDesk had to be discarded to make it fit on a 140K floppy disk for those systems not featuring a 3.5” UniDisk drive!

The Apple IIGS Finder made its appearance about two years after the release of the Apple IIGS. And when it did make its appearance, it elevated the Apple II desktop to the sophistication of the Macintosh SE (where the system software was concerned). The first versions of the Finder exploited the 65C816 processor and the 16-bit Apple IIGS Toolbox (based in concept on the original Macintosh Toolbox), improving the capacity and the stability of the system, while allowing the Apple IIGS to take advantage of its memory capacity and its new graphics capabilities. However, the first incarnations of the Apple IIGS Finder were plagued with performance problems, mostly due to deficiencies in the Apple IIGS Toolbox.

As Apple released updates to the Apple IIGS system software, some of these performance problems dissipated – the latest and last Apple IIGS system software release (System Software 6.0.1) performed desktop graphics operations 3-5 times faster than the original Apple IIGS Finder (System Software 3.0) without changing the hardware, except for perhaps a 1 MB memory upgrade. The last incarnation of the IIGS Finder presented a rather clean, easy-to-understand and familiar interface for those who have used Macintosh. And for those who haven’t used Macintosh... well... it served as a darn good equivalent, with some impressive bridging technologies made available to allow Apple IIGS computers to fit in within a Macintosh world.

Apple IIGS System Software loading
This image can be zoomedApple IIGS System Software loading
Apple IIGS System Software desktop
This image can be zoomedApple IIGS System Software desktop
Apple IIGS System Software icons
This image can be zoomedApple IIGS System Software icons

Apple IIGS Get Info dialog
This image can be zoomedApple IIGS Get Info dialog
Apple IIGS System Software file copying
This image can be zoomedApple IIGS System Software file copying
Apple IIGS System Software question dialog
This image can be zoomedApple IIGS System Software question dialog

Apple IIGS System Software notification message
This image can be zoomedApple IIGS System Software notification message
Apple IIGS System Software shut down
This image can be zoomedApple IIGS System Software shut down

Two of the most important Apple IIGS applications (apart from all those games!), were AppleWorks GS and HyperCard. Both applications showcased the power of the Apple IIGS system software – in some cases, it even excelled its Macintosh counterparts.

AppleWorks GS provided compatibility with data files from the original AppleWorks (for the classic Apple II), with new graphics capabilities. Some parts of AppleWorks GS are reminiscent of some of the applications that appeared on the Macintosh (such as MacTerminal and MacWrite). It is apparent here that the Apple IIGS Toolbox implemented most of the original Macintosh controls – menus, buttons, scrollbars and thumbs, and window titles. Coupled with nearly a 2:3 aspect ratio for every pixel on the display, and a restricted vertical resolution of a mere 200 lines, the Apple IIGS had a much harder job in rendering the Macintosh desktop user interface, particularly radio buttons, where circles were not drawn as perfect circles! Fortunately for the less-powerful machine, user interface objects were pre-rendered in later system software releases, which meant the consumption of more memory space, with the disadvantage that controls were not resizable.

AppleWorks GS open file dialog
This image can be zoomedAppleWorks GS open file dialog
AppleWorks GS word processor
This image can be zoomedAppleWorks GS word processor
Windows in AppleWorks GS
This image can be zoomedWindows in AppleWorks GS

HyperCard GS was another application that took an originally Macintosh application into new territory. HyperCard for the Macintosh never supported colour natively, but unlike the Apple IIGS, had a larger screen size to implement much sharper high resolution monochrome graphics with larger card sizes. Nevertheless, HyperCard GS was a window-less application, and exploited the entire desktop to implement its cards.

HyperCard GS welcome screen
This image can be zoomedHyperCard GS welcome screen
HyperCard GS accessories
This image can be zoomedHyperCard GS accessories

So far, all Apple IIGS screenshots have used the Super-High-Resolution 640 mode, most often used by applications that did not rely on the extensive use of colour. However, the Apple IIGS Toolbox also supported the desktop in Super-High-Resolution 320 mode, which probably looked rather strange and – due to the severe restriction in screen real-estate – not as practical in implementing Apple’s graphical user interface. Notice the window sizes of desk accessories... they all tended to be taller than they were wider. That was because they had to be no wider than half of a 640-wide display, simply so that they could be fully contained within a 320-wide one!

Desk accessories
This image can be zoomedDesk accessories
BeagleDraw menu
This image can be zoomedBeagleDraw menu

On the left screenshot, BeagleDraw, a program that resembled MacDraw for the Macintosh, is buried underneath those desk accessories... somewhere! Find File was one example of the rather serious restrictions imposed on desk accessories due to the nature of the Apple IIGS’s display, and the inherent need to support the lowest common denominator of Apple IIGS features. And often, Apple IIGS programs made demanding use of the display’s colour palettes (there were only 16 colours assignable per scan line), which often caused some user interface features, particularly desk accessories, to look weird.

BeagleDraw took another step in making the Super-High-Resolution 320 mode work – it used Geneva 9 bold as the system font rather than the default system font, Shaston 8 (used here in the labels for the bars in the mock-up bar chart). Obviously, Shaston 8’s character width was significantly wider than that of Geneva 9, and considering BeagleDraw had already taken up all of the screen width for its menu bar, it was obvious why the developers could not stick to the standard Apple IIGS system font to implement its menus!

I have purposely tried to limit this discussion to Apple II system software and applications by Apple Computer, because usually, the company that makes the system is the one that establishes the guidelines for writing software for that system. And Apple have evidently applied user interface, or at least, ease-of-use, guidelines to their software for both text and graphics environments since almost the very start of the Apple II’s career into personal computing. The inclusion of some of the more interesting third-party applications that adopted a graphical user interface has been made in contrast to what had become Apple’s standard user interface design for both the Apple II and the Macintosh.

While today’s user interface designs and concepts are much more sophisticated than the ones older computers had to deal with or implement, it is interesting how developers dealt with various problems in user interface design, especially on an Apple II. The Apple II has been an interesting architecture to study, because it was literally a very limited piece of hardware that had to live up to the expectations from a company that produced Macintosh.

I hope you have had fun reading this article as much as I had fun writing it!

by Tony Kavadias

Page added on 24th July 2004.

Copyright © 2002-2006 Marcin Wichary, unless stated otherwise.