|
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 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 |
 | | ProDOS User’s Disk |
 | | ProDOS 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 |
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 |
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 |
 | | Main menu of AppleWorks |
 | | File interface of AppleWorks |
Interestingly enough, other components of AppleWorks didn’t use MouseText:
 | | AppleWorks database categories |
 | | AppleWorks database |
 | | AppleWorks word processor |
 | | AppleWorks 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 |
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.
 | | MousePaint |
 | | One 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 |
 | | BeagleWrite 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.
 | | MouseDesk |
 | | MouseDesk File menu |
 | | MouseDesk 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 |
 | | MouseDesk Quick Copy dialog |
 | | MouseDesk 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 |
To demonstrate how incomplete MouseDesk was as a system utility...
 | | Apple 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 |
 | | Apple IIGS System Software desktop |
 | | Apple IIGS System Software icons |
 | | Apple IIGS Get Info dialog |
 | | Apple IIGS System Software file copying |
 | | Apple IIGS System Software question dialog |
 | | Apple IIGS System Software notification message |
 | | Apple 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 |
 | | AppleWorks GS word processor |
 | | Windows 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 |
 | | HyperCard 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 |
 | | BeagleDraw 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
| 
Home 
