Computer History Museum
AI-assisted summary of Origins of the Apple Human Interface — original source. Check the original for full context.
Source published:
Key ideas
- Larry Tesler and Chris Espinosa recount the genesis of the Apple Human Interface, relying on 1979–1980 internal specifications to document how Apple departed significantly from Xerox PARC through empirical usability testing rather than direct imitation. (6:34)
- Apple instituted rapid user testing with naive subjects—including first-day Apple employees and external non-computer users—to settle design debates on single-button mice, screen-top menu bars, and cut-and-paste paradigms. (35:19)
- Macintosh user interface discipline merged Lisa's graphical mouse mechanics with the Apple II division's documentation-driven consistency standards, overcoming fierce third-party developer pushback against ROM-based UI uniformity. (87:08)
- Early office suite strategies assumed users only needed a bundled core suite, a premise that crippled Lisa commercially due to high costs and closed software ecosystems before being vindicated decades later by Microsoft Office. (108:41)
Detailed notes
## Background Published on YouTube by the Computer History Museum on February 28, 2019, this video captures a historical lecture delivered on October 28, 1997, by Larry Tesler and Chris Espinosa. As described in the museum archives, the presentation explores the origins and evolution of the Apple Human Interface across the development of the Lisa, Macintosh, and Apple II.
## TL;DR Larry Tesler and Chris Espinosa deliver an archival, document-backed breakdown of how Apple established its foundational graphical user interface standards between 1979 and the mid-1980s. Tesler details the intense technical debates and rapid usability testing behind the Lisa that yielded the single-button mouse, top-of-screen menu bars, standardized keyboard shortcuts, and the desktop icon metaphor. Espinosa traces the parallel usability efforts within the Apple II team, showing how retail tutorials and documentation deadlines established the disciplined developer guidelines later inherited by the Macintosh. Together, they dispel the myth that Apple merely cloned Xerox PARC, highlighting how rigorous empirical testing with complete novices fundamentally reshaped personal computing.
## Atmosphere & style The presentation carries the warm, reflective, and candid intimacy of two Silicon Valley veterans speaking to an audience of peers, former colleagues, and computing pioneers. Tesler offers a dry, methodical, and self-deprecating retrospective fueled by contemporaneous internal memos, sharing wry amusement over bureaucratic design councils and technical compromises. Espinosa adds an energetic narrative counterpoint steeped in early Apple culture and cognitive psychology, creating an engaging session that strips away corporate mythology to reveal the pragmatic, midnight engineering that built modern interface conventions.
## Bulletin - [06:34](https://www.youtube.com/watch?v=OW-atKrg0T4&t=394s) Larry Tesler and Chris Espinosa recount the genesis of the Apple Human Interface, relying on 1979–1980 internal specifications to document how Apple departed significantly from Xerox PARC through empirical usability testing rather than direct imitation. - [35:19](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2119s) Apple instituted rapid user testing with naive subjects—including first-day Apple employees and external non-computer users—to settle design debates on single-button mice, screen-top menu bars, and cut-and-paste paradigms. - [01:27:08](https://www.youtube.com/watch?v=OW-atKrg0T4&t=5228s) Macintosh user interface discipline merged Lisa's graphical mouse mechanics with the Apple II division's documentation-driven consistency standards, overcoming fierce third-party developer pushback against ROM-based UI uniformity. - [01:48:41](https://www.youtube.com/watch?v=OW-atKrg0T4&t=6521s) Early office suite strategies assumed users only needed a bundled core suite, a premise that crippled Lisa commercially due to high costs and closed software ecosystems before being vindicated decades later by Microsoft Office.
## Key takeaways - [01:37:37](https://www.youtube.com/watch?v=OW-atKrg0T4&t=5857s) Apple's interface was not a direct clone of Xerox PARC; while adopting overlapping windows and desktop concepts, Apple introduced drag-and-drop, the single-button mouse, and the global screen-top menu bar. - [06:34](https://www.youtube.com/watch?v=OW-atKrg0T4&t=394s) Larry Tesler's anti-mode crusade ('Don't Mode Me In') from Xerox PARC drove Apple to minimize modal application states and streamline direct manipulation. - [17:42](https://www.youtube.com/watch?v=OW-atKrg0T4&t=1062s) Lisa and Macintosh target users were explicitly non-technical office workers and secretaries, prompting strict design priorities over programmer-centric conventions like Emacs commands or command trees. - [35:19](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2119s) The single-button mouse was championed by Larry Tesler, Bill Atkinson, and Trip Hawkins to eliminate cognitive friction and ensure compatibility with future alternate input devices. - [44:41](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2681s) Bill Atkinson solved pathological window border clipping and menu clutter in September 1980 by moving the menu bar from individual window headers to the top of the physical screen. - [46:44](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2804s) Usability testing protocols were formalized to prevent engineering bias, forbidding software developers from arguing, coaching, or patronizing test subjects. - [46:44](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2804s) Prompting users with conversational framing like 'bring me the...' revealed natural vocabulary, helping designers establish intuitive UI naming conventions. - [49:46](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2986s) Lisa management temporarily transferred interface authority to a five-person administrative council voting by majority rule, prompting engineers to deploy empirical testing data to defend design choices. - [01:06:09](https://www.youtube.com/watch?v=OW-atKrg0T4&t=3969s) The iconic desktop interface was adopted over the list-based filer not because of operational speed or lower error rates, but strictly due to overwhelming user visual preference. - [01:18:14](https://www.youtube.com/watch?v=OW-atKrg0T4&t=4694s) Apple II usability testing by Bruce Tognazzini relied on silent observation of user body language (squints, sighs, hunched shoulders) to diagnose points where software failed. - [01:21:06](https://www.youtube.com/watch?v=OW-atKrg0T4&t=4866s) Iterative prompt testing on the Apple IIe tutorial demonstrated how minor phrasing shifts ('appear in several different colors') resolved monitor compatibility confusion that logic-based wording failed to fix. - [01:27:08](https://www.youtube.com/watch?v=OW-atKrg0T4&t=5228s) Third-party software developers initially resisted the uniform Macintosh ROM Toolbox, fearing consistent system-wide UI standards would erase their competitive application differentiation. - [01:29:15](https://www.youtube.com/watch?v=OW-atKrg0T4&t=5355s) Field testing on Renault mechanics using HyperCard illustrated how physical workplace posture and paper documentation workflows directly inform software navigation design. - [01:52:24](https://www.youtube.com/watch?v=OW-atKrg0T4&t=6744s) Chris Espinosa observed a three-year-old child master MacSketch within 20 seconds, proving that intuitive graphical interfaces bypass cultural conditioning and language barriers.
## Detailed walkthrough ### [01:01](https://www.youtube.com/watch?v=OW-atKrg0T4&t=61s) Building the Computer History Museum Collection
Opening the evening's gathering at NASA Ames Research Center, the host lays out the ambitious roadmap for establishing a permanent, public computer history museum. Rather than a hands-on science center catering primarily to children, this institution is explicitly conceived as an adult-oriented repository dedicated to preserving the full record of computing history: hardware, software, documentation, and archival ephemera. Realizing this vision is projected as a four- to five-year undertaking centered on acquiring land and constructing a custom facility. In the interim, the team is aggressively expanding what is already considered the finest collection of computing artifacts in the world, containing thousands of physical machines, historical photographs, manuals, and technical texts.
To support the center's growth, attendees and the wider technical community are invited to participate through weekend volunteer workdays and tiered membership options. A baseline $100 annual membership provides access to the History Center and grants security credentials to enter Moffett Field on Wednesdays and Saturdays to examine the visible storage collection without repeating standard base security procedures. In addition, a time-limited founding membership program offers individuals donating $1,000 or more permanent enshrinement as founders of the Computer History Center, mirroring the foundational campaign executed by the Computer Museum in Boston a decade earlier.
Beyond local archiving, the institution has begun organizing external exhibitions at industry conferences and academic hubs, including an upcoming installation at Stanford University's newly opened Gates Computer Science Building to showcase selections of the archive before permanent museum galleries exist. Meanwhile, cross-country logistics are actively underway: four semi-trailer trucks loaded in Boston are traversing the United States carrying historic hardware, including the RAND JOHNNIAC and an MIT Connection Machine CM-5 from Thinking Machines, alongside other landmark computing artifacts.
- Membership options: $100 annual pass granting streamlined base access to Moffett Field visible storage on Wednesdays and Saturdays; $1,000 founding membership open for a six-month window. - Active transit: Four tractor-trailers hauling historic machinery from Boston to California, including the JOHNNIAC and the MIT CM-5. - Venue gratitude: Appreciation extended to NASA Ames for supplying conference facilities and vital warehouse storage space for the growing collection.
---
[03:56](https://www.youtube.com/watch?v=OW-atKrg0T4&t=236s) Bay Area Computer History Perspectives and Speaker Introductions
Peter Speer steps forward to introduce the program, clarifying that the Bay Area Computer History Perspectives series is a collaborative venture organized alongside Jeannie Treichel, an alumna of Xerox PARC. Both now work at Sun Microsystems. Operating for over four years since its inception, the speaker series has established a loyal following among Bay Area computing pioneers; Speer points out Norm Hardy and George Michael of the Lawrence Livermore National Laboratory seated in the front row, both of whom presented at the series' very first session.
Speer notes that featured speaker Larry Tesler is also a returning presenter, having delivered a lecture three years prior alongside Bob Harriet, Larry Breed, and Don Wise concerning the early Stanford card stunts. Speer characterizes that historic collegiate stunt as effectively the world's largest early bitmap display, requiring thousands of coordinated students to hoist colored placards according to programmed sequential instructions.
Turning to the evening’s presentation on the origins of the Apple user interface, Speer introduces Larry Tesler and Chris Espinosa. Larry joined Apple from Xerox PARC in 1980, assuming he would be introducing foundational user interface principles to the company, only to discover that Apple had already undertaken independent user testing and UI experimentation. Co-presenter Chris Espinosa represents the earliest days of Apple's culture, having joined the company as a high school student—likely the youngest employee in Apple's corporate history—demonstrating early Apple systems while still a teenager.
---
[06:34](https://www.youtube.com/watch?v=OW-atKrg0T4&t=394s) Setting the Record Straight on Xerox PARC, Smalltalk, and Modelessness
Taking the podium, Larry Tesler explains that the evening's talk is based on an internal presentation he and Chris Espinosa gave at Apple in July, which only received formal legal clearance for public disclosure two to three weeks prior. Tesler emphasizes the challenge of reconstructing user interface history without revisionist distortion. As Tesler puts it: “Asking about what was early user interface design at Apple is kind of like asking about early engine design at Mercedes-Benz or something; everybody was doing it.” To counteract the natural human tendency of memory to fade or self-aggrandize over seventeen years, Tesler and Espinosa have anchored their talk almost entirely in original, contemporaneous technical memos, specifications, and internal documents from 1979 through the early 1980s.
Tesler addresses the persistent narrative in the computer trade press that Apple simply copied the graphical user interface from Xerox PARC whole cloth. Presenting the August 1981 Smalltalk issue of *Byte* magazine, which featured an article written by Tesler, he walks through what the Smalltalk environment actually looked and behaved like on Xerox hardware. The Smalltalk interface relied on austere rectangular title bars, scrollbars entirely devoid of directional arrow buttons, and dual pop-up menus dedicated to each individual window. While Xerox's work profoundly inspired Apple, the mechanics of the interface differed significantly from what eventually materialized on the Lisa and Macintosh.
Central to Tesler's work at Xerox PARC was his personal philosophical campaign against software modes. He shares a photograph of a custom t-shirt gifted to him by a friend emblazoned with the slogan "Don't Mode Me In," capturing his relentless effort to eradicate modal states where identical keystrokes or mouse clicks produced drastically different results depending on the application's hidden internal status. Tesler wryly reflects that eliminating every mode was not necessarily an unvarnished design virtue in practice, though it drove his early work. Following Apple's formal licensing of Smalltalk alongside Hewlett-Packard, Digital Equipment Corporation (DEC), and Tektronix, widespread commercial adoption was ultimately achieved not by the major hardware vendors, but by independent software companies.
```mermaid flowchart TD accTitle: Influence of Xerox PARC Smalltalk on Apple UI accDescr: Diagram tracing the transmission of Smalltalk ideas and UI primitives into the Apple Lisa project.
subgraph XeroxPARC["Xerox PARC Smalltalk-80"] ST_UI["Smalltalk UI Primitives - Rectangular title bars - Dual pop-up menus per window - Arrowless scrollbars"] Modeless["Design Philosophy - 'Don't Mode Me In' - Elimination of modal states"] end
subgraph AppleLisa["Apple Lisa Development (1980)"] AppleTesting["Apple In-House Testing - Pull-down menus - Intuitive desktop metaphors - Bulletproof error handling"] end
ST_UI -->|"Inspiration, not direct clone"| AppleTesting Modeless -->|"Elimination of modes"| AppleTesting ```
---
[09:47](https://www.youtube.com/watch?v=OW-atKrg0T4&t=587s) The Lisa Usability Results and Larry Tesler's Arrival at Apple
Before diving into the chronological evolution, Tesler jumps ahead to the finished Apple Lisa to illustrate the project's ultimate usability achievement. In 1980, the personal computer market was dominated by the command-line Apple II; while universally beloved by enthusiasts, mastering it demanded a steep, time-consuming learning curve. The Lisa team set out to construct a graphical system so intuitive that a novice office worker could master basic workflows within minutes. Usability validation conducted at the conclusion of Lisa's development tested 18 non-technical subjects across three foundational office applications: six on the business graphing tool LisaGraph, six on the word processor LisaWrite, and six on the flat-file database manager LisaList. For seventeen out of the eighteen subjects, achieving functional core competency required under 20 minutes, with only a single LisaList user exceeding that threshold. Tesler observes that the Lisa was in several respects simpler and more bulletproof than the subsequent Macintosh, because the team engineered extensive structural guardrails to guarantee users could never drive the machine into unrecoverable states.
Tesler then shifts back to the beginning of his tenure at Apple, which commenced on July 17, 1980, inaugurating a 17-year career at the company. Displaying a corporate memo dated July 18, 1980—his second day on the job—Tesler recalls the dramatic culture shock of transitioning from corporate Xerox PARC to a relentless Silicon Valley startup. As Tesler describes the experience: “One thing I discovered when I left big Xerox Corporation and went to this little Apple startup was that you just really get engaged immediately and they put you right to work.”
Upon his arrival, Lisa project leadership bluntly informed Tesler that the user interface design was essentially finished and ready for final documentation and coding. They expressed polite regret that he had taken so long to report to the office, because the window for input had closed: all final interface decisions had to be locked down by July 23—a mere five days away—and the complete External Reference Specification (ERS) had to be finalized just one week later. When management insisted that the schedule was fixed but that quality could not be compromised under any circumstances, Tesler pushed back, explaining that proper interface engineering required months of rigorous human-subjects testing and careful iterative refinement.
- Usability metrics: 17 out of 18 test subjects achieved core competency in LisaGraph, LisaWrite, or LisaList in under 20 minutes. - Tesler's arrival timeline: Started on Thursday, July 17, 1980; presented with a hard interface lock deadline of Wednesday, July 23, 1980; full External Reference Specification (ERS) due by July 30, 1980.
[12:01](https://www.youtube.com/watch?v=OW-atKrg0T4&t=721s) The Aggressive Five-Day Schedule and Two-Day Test Plan
Faced with severe management pressure to design software in an impossibly short window—being told there were only five days before a weekend—the team hammered out an intensely aggressive schedule where every participant promised to deliver their part. Larry Tesler reviews the slide showing the plan laid out for July 21 and 22, 1980, laughing as he tries to figure out the slide pointer before realizing Chris Espinosa is holding the laser. The Monday plan started with internal evaluation: the team would spend two hours testing Bill Atkinson's latest prototype. Atkinson was responsible for building the prototypes at that stage and dreaming up many of the foundational interface concepts.
```mermaid flowchart TD accTitle: Rapid Evaluation Schedule July 1980 accDescr: Schedule for reviewing Bill Atkinson's prototype and testing it with Steve Jobs and users
subgraph Monday["Monday: Internal Review & Decision"] M1["Try Bill Atkinson's Prototype (Internal Team)"] --> M2["Consult Sue Espinosa (Head of Training)"] M2 --> M3["Discuss Remaining UI Issues"] M3 --> M4["Present to Steve Jobs for Decisions"] end
subgraph Tuesday["Tuesday: User Testing"] T1["Test Two User Subjects (9:00 - 10:00)"] --> T2["Test Two More Subjects (10:00 - 12:00)"] T2 --> T3["Evaluate Test Results (1:00 - 3:00)"] end
Monday --> Tuesday ```
Following a lunch break at 1:00 PM, the schedule brought in Sue Espinosa, head of training and coincidentally Chris Espinosa’s mother, to evaluate what would be easiest to teach novice users. At 2:00 PM, the team scheduled an hour to hash through the remaining issues, operating under the optimistic assumption that they would resolve everything right then. From 3:00 to 5:00 PM, they arranged to present their work to Steve Jobs for executive decisions, which Tesler notes dryly were guaranteed to be decisive. Tuesday was reserved for empirical validation: taking whatever Steve approved and running it past real test subjects in rapid one-to-two-hour blocks between 9:00 AM and noon, followed by an afternoon evaluation of the data.
- **Internal testing**: 2-hour morning session with Bill Atkinson’s interactive prototype. - **Training input**: 1:00 PM review with Sue Espinosa to assess trainability. - **Executive approval**: 3:00–5:00 PM session with Steve Jobs to lock in interface decisions. - **User testing**: Four external test subjects evaluated in two morning shifts on Tuesday.
---
[14:26](https://www.youtube.com/watch?v=OW-atKrg0T4&t=866s) The External Reference Specification and Target Audience
The team actually executed the two-day blitz, gathering user observations and incorporating Steve Jobs’s input. Atkinson then sat down to draft the external reference specification (ERS) for the user interface. Tesler admits he felt uneasy about finalizing a specification when they had only tested a handful of concepts rather than conducting exhaustive trials. The resulting document was dated August 6, 1980—already slipping a few days past their self-imposed July deadline—and granted reviewers just one week to send in feedback.
Tesler reviews the recipient list on the memo, pointing out names that proved historically significant. Copies went to Ken Victor, Barry Smith, and Jef Raskin, alongside Apple co-founders Steve Jobs and Mike Markkula, and head of product marketing Trip Hawkins. The entire Lisa software group received copies, whereas Lisa hardware was sent only a single shared copy. Memos were distributed to every vice president the team could think of, as well as future Apple Fellows Rod Holt and Steve Wozniak, whom Tesler spots sitting in the back of the auditorium and acknowledges warmly.
Crucially, Atkinson’s document opened by rigorously defining the target customer rather than settling for a vague mandate to make a "friendly" computer. The Lisa was defined specifically as a single-user office workstation aimed at enriching the productivity of office personnel. It was not intended to run thousands of arbitrary third-party programs. Instead, it was tailored for a core suite of integrated applications: word processing, graphics, data management, and communications. As Tesler explains, “The concept that Trip Hawkins had was they had done studies and they found that most people on the Apple II ended up using only two or three applications; therefore, this was the great leap: all we need to do is provide two or three applications, that's all anybody will ever want.”
---
[17:42](https://www.youtube.com/watch?v=OW-atKrg0T4&t=1062s) Designing for Non-Analytical Office Workers: The Couch Mantra
The driving operational philosophy came from John Couch, the head of the Lisa project, who framed the engineering mission with the rhetorical ambition of John F. Kennedy's pledge to land a man on the moon and return him safely. Whenever technical disputes arose, Couch would recite his core workflow demand: “All I want is I want to be able to go into a spreadsheet, make some put some numbers in, go and graph them, take the graph, paste it into my word processor document and include it in a report.” That single vision kept the engineering team strictly focused on seamless inter-application integration, setting Lisa apart from the Apple II's isolated software silos.
The specification explicitly defined the expected user base as non-technical and non-analytical first-time users. In 1980, nearly every office employee was touching a computer for the first time. The primary target personas were administrative assistants and secretaries, with managers, accountants, and executives categorized secondarily. The machine was emphatically not built for programmers, children, or home hobbyists tracking kitchen recipes. This narrow enterprise focus shaped architectural choices that would distinguish the Lisa from the later consumer-oriented Macintosh and create parallels with early desktop workstations. The design philosophy outlined four core interaction pillars: graphic images, on-screen menus, a freely movable pointing device to replace arrow keys, and supplemental keyboard shortcuts for repetitive tasks where using a mouse might slow an operator down.
---
[18:47](https://www.youtube.com/watch?v=OW-atKrg0T4&t=1127s) Early Hardware and Window Mechanics: Keyboards, Two-Button Mice, and Title Tabs
Turning to the physical Lisa hardware that existed when he joined Apple, Tesler shows the original keyboard layout. To achieve the compact physical width industrial designers wanted, the keys could not accommodate every character on their top surfaces. The engineers solved this by printing additional characters onto the vertical front faces of keycaps and adding an unfamiliar "Code" key in the top-left corner to access them. Coming from Xerox PARC, Tesler wanted to overhaul the hardware, but management shut him down, telling him that research-lab redesigns were out of the question because the Lisa had to ship in six months—a deadline that slipped from 1980 until mid-1983, a delay Tesler jokingly assumes was probably his fault.
```mermaid flowchart LR accTitle: 1980 Title Tab Window Control Interactions accDescr: How clicks and drags on the title tab operated window management functions using two mouse buttons
subgraph MouseActions["Mouse Input on Title Tab"] PB["Point Button"] GB["Grow Button"] end
subgraph Operations["Window Manager Result"] PB -->|"Click"| W1["Display Window Menu / Toggle Open-Close"] PB -->|"Drag"| W2["Move Window Across Desktop"] GB -->|"Drag / Click"| W3["Change Window Size"] end ```
The pointing device at the time was a rectangular, brick-shaped mouse with two distinct buttons: the "Point" button and the "Grow" button. Tesler displays his handwritten margin notes from 1980, questioning the ergonomics of the brick casing and debating whether the two buttons should sit completely flush or have physical separation. Window management had no lower-right grow box or standardized top menu bar. Instead, all window state changes were concentrated directly inside the window's "title tab": - Clicking the Point button in the title tab could open, close, or display a window-specific menu. - Dragging with the Point button relocated the window across the screen. - Engaging the Grow button while interacting with the title tab resized the window dimensions.
A menu bar did exist across the bottom border of the window, but it handled document contents rather than window behavior. In an archival diagram sent to Jef Raskin, the window placed its vertical scrollbar on the far left rather than the right edge. Notably, both horizontal and vertical scrolling arrows were clustered tightly together—a configuration designed by Bill Atkinson in 1980 that minimized mouse travel, anticipating an identical approach adopted years later by NeXT. At the bottom of this layout sat an Edit menu offering Cut, Paste, "Dup" (for duplicate), and Undo, while primitive file and document representations lined the margin as precursors to modern desktop icons.
[22:03](https://www.youtube.com/watch?v=OW-atKrg0T4&t=1323s) Windows, Dialog Boxes, Scroll Bars, and Alert Boxes
Larry Tesler outlines the interface ideas that the Apple team had drafted by August 1980. The concept of window collapsing was borrowed straight from Smalltalk: a user could take the tab of a window, discard the body of the window, keep only the tab, and treat it as a window that remained available but currently closed, ready to be reopened at will. They also introduced an early precursor to dialog boxes called "fill-in menus." These took two forms: one where the user opened a submenu and typed directly into it, and another where the interface spawned an entire dedicated box, then called "forms." Tesler notes that at the time, no drawings or mockups had yet been made to clarify what these forms would actually look like. He also recalls noting his disagreement in the specification regarding menu commands being invokable from the keyboard, reflecting: “I think I was afraid they would do too much keyboard stuff.”
```mermaid flowchart TD accTitle: Early Window and Menu Mechanics accDescr: Flow diagram showing Smalltalk-inspired window collapsing and fill-in menus. subgraph Windows["Window Management"] W1["Open Window"] -->|"Collapse window"| W2["Retain Tab Only"] W2 -->|"Open tab"| W1 end subgraph FillInMenus["Fill-in Menus (Early Dialogs)"] F1["Trigger Menu"] --> F2["Type into Submenu"] F1 --> F3["Spawn 'Forms' (Full Dialog Box)"] end ```
The scrolling mechanics incorporated both continuous scrolling and an experimental paging model. To scroll continuously, the user held down a mouse button. A more unconventional proposal was to allow a double click to flip directly to the next page. Tesler notes that good user interface design generally dictates that a first click initiates an action without the second click negating what just occurred; in this case, clicking once would start scrolling a tiny amount, and the second click would prompt the system to realize the user wanted a full-page jump:
> “So you'd get a little motion and then a jump, which actually might have been kind of cute, but I don't think we ever implemented it.”
The scroll bar also featured the "elevator shaft" containing an "elevator"—the term then used for what is today called the scroll box or thumb.
Other interface elements included: - **Abbreviations Window:** Tied to the hardware "Code" key on the keyboard, inspired by Wang dedicated word processors. A secretary could press Code and a letter key to look up shorthand entries in a table and expand full phrases. - **System Error Window:** The direct ancestor of Mac and Windows alert boxes, designed to emit a beep and explain the failure condition. - **Modal vs. Modeless Alert Behavior:** Tesler had written a question mark in the margins asking whether the system was frozen while the error window was up. The team ultimately decided that alert boxes had to be modal, though resolving that question took considerable debate.
---
[24:33](https://www.youtube.com/watch?v=OW-atKrg0T4&t=1473s) The August 1980 Interface Design: Smalltalk Meets UCSD Pascal and HP
Tesler highlights the team's early commitment to usability testing. The project specification claimed that the interface was already based on studies of user reactions to various models, even though that amounted to only three or four hours of testing with a handful of people. Nevertheless, the spec promised further user testing to avoid glaring design flaws. Tesler welcomed this mandate because he knew the team had not tested enough and needed cover to find and fix the defects still lingering in the design.
```mermaid flowchart LR accTitle: Lineage of the August 1980 Lisa Interface accDescr: Diagram tracing UI elements from Smalltalk, UCSD Pascal, and HP computers into the early Lisa specification. ST["Smalltalk"] -->|"Overlapping windows, title bar, left scrollbar"| Lisa["Lisa UI (August 1980)"] UCSD["UCSD Pascal"] -->|"Hierarchical single-letter menus"| Lisa HP["HP Terminals/Computers"] -->|"Bottom-of-screen menus aligned to top function keys"| Lisa ```
The resulting August 1980 mockups reflected a hybrid lineage drawn from the development environments the team members knew best: - **Smalltalk Influences:** The interface retained overlapping windows, a title bar box at the top, and a scroll bar positioned along the left edge. However, whereas Smalltalk required pressing a button to make scroll arrows appear, the Lisa team insisted on persistent scroll arrows to give users a concrete target to point at. - **UCSD Pascal and HP Influences:** At the bottom of the screen was a horizontal menu bar. Half the engineering team had come from Hewlett-Packard, while others relied on UCSD Pascal for daily software development. In UCSD Pascal, users typed the first letter of an item to descend through hierarchical menus; on HP computers, a row of function keys across the top of the keyboard corresponded directly to menu labels arranged along the bottom edge of the display screen. The Lisa design blended these concepts, allowing operations either through hierarchical keystrokes or function keys. - **The Wastebasket Metaphor:** Cut and paste were supported as menu commands, but cut text was routed to a temporary storage space labeled the "wastebasket" rather than the clipboard. The idea was patterned after an office worker snipping scrap paper and tossing it into a bin, from which it could be retrieved and pasted elsewhere. Because this later produced serious confusion with the desktop "trash can," the name was subsequently abandoned.
---
[26:56](https://www.youtube.com/watch?v=OW-atKrg0T4&t=1616s) Ken Victor's Feedback and the "Cut/Paste vs. Move/Copy" Debate
Reviewer Ken Victor submitted rapid feedback on the August specification, raising several fundamental objections that exposed deep philosophical divisions within the engineering staff. First, Victor challenged why text could only be selected using the mouse, advocating an Emacs-style keyboard navigation model where users could specify targets by coordinate or occurrence (such as the fourth line, third word, seventh character, or the fourth occurrence of a specific word). Tesler explained that while Victor was an advanced power user who wanted those shortcuts, the intended office market was entirely different: secretaries and office workers could simply look at the screen and point to the words they saw.
Victor also pushed back on window manipulation and scrolling: - **Window Resizing:** The draft specified growing windows from the lower right (or ambiguously from the top). Victor insisted users should be able to drag and grow a window from any border or corner. Tesler admits Victor was right: “I do think that's better, and we didn't pay any attention to him; I think we were worried about the screen space being too tight or something.” - **Live Scrolling:** Victor asked for real-time scrolling where text would track continuously as the elevator moved up and down the shaft. This proved computationally impossible because the Lisa's Motorola 68000 processor ran at roughly 5 MHz and could not refresh the screen fast enough.
```mermaid flowchart TD accTitle: Debate Between Move-Copy-Delete and Cut-and-Paste accDescr: Comparison of two-point editing versus the intermediate clipboard model in early Apple design. subgraph TwoPoint["Ken Victor: Move / Copy / Delete"] M1["Select Source"] --> M2["Specify Command + Destination Simultaneously"] M2 --> M3["Immediate Relocation"] end subgraph Clipboard["Larry Tesler: Cut / Copy / Paste"] C1["Select Source & Cut/Copy"] --> C2["Placed in Wastebasket / Clipboard"] C2 --> C3["Navigate to Destination (Any Window / Page)"] C3 --> C4["Paste"] end ```
Victor strongly objected to the cut-and-paste paradigm, demanding a model based on "move," "copy," "delete," and "transpose," where a user explicitly marked two locations to move or copy content from one spot to another. Tesler recalls this as one of the great religious debates in user interface history, akin to arguing over single-button versus two-button mice. While cut-and-paste required two separate operational steps, Tesler defended it on several crucial grounds: - **Source and Destination Visibility:** Move/copy commands require both the source and the target destination to be visible at the same time to specify the action. On a limited screen with overlapping windows, arranging two windows side-by-side without them obscuring each other was extremely frustrating. Cut-and-paste allowed the user to cut an item, put it in an intermediate buffer, freely navigate elsewhere, and paste it. - **Tesler's Publishing Agenda:** While Apple management framed the Lisa as an office system, Tesler envisioned it as a premier engine for page makeup and desktop publishing: “I had a secret agenda, which is I thought that the machine should be used not for what they talked about—office systems... I thought it would be a great machine for publishing, and that would be able to do cut and paste into page layout.” - **User Preference:** User testing showed that office subjects slightly preferred the cut-and-paste model. - **Buffer Capacity:** Victor argued that the wastebasket window should hold multiple cut items in a queue rather than just one item at a time. Other designers insisted on a single-item buffer; Victor lost that debate in the end.
---
[30:31](https://www.youtube.com/watch?v=OW-atKrg0T4&t=1831s) Response Times and Keystroke Fixations
Reviewing the specifications himself, Tesler lodged formal complaints about performance benchmarks. The specification documented expected user workflows in minute detail, but it omitted all performance and response-time criteria. Tesler warned that unless hard metrics were written into the engineering requirements (e.g., specific interactions executing within half a second, two seconds, or ten seconds), the engineers would never optimize performance:
> “If any of you ever used a Lisa, well, it was really slow. I lost that argument; they said, 'It'll be as fast as we can make it,' and that was too slow.”
Tesler also attacked the software team's persistent fixation on UCSD Pascal-style hierarchical menus. The idea of navigating software entirely by typing a key, waiting for a submenu, typing another key, and descending down a textual tree struck him as deeply misguided for a modern graphical interface, prompting him to search for a better way to marry keyboard access with graphical menus.
[31:19](https://www.youtube.com/watch?v=OW-atKrg0T4&t=1879s) August 13, 1980: Windows, Scrollbars, and the Xerox Confidentiality Dilemma
Larry Tesler reflects on the deep flaws of hierarchical menu structures, noting that users inevitably get trapped and confused: “A lot of mistakes could be made, people are gonna forget which level of the hierarchy they're in, how they get back out of it again, it's just gonna be too complicated and I didn't like it.” His complaints also extended to the mouse hardware. The team was using a two-button mouse, but the secondary button saw very little practical use, and whenever it was assigned a purpose, users found it impossible to remember which button did what. Tesler’s stance was blunt: eject the second button entirely and standardize on a single button.
Turning to window mechanics in his August 13 memo, Tesler proposed several foundational interaction mechanisms. He advocated placing a dedicated sizing box in the lower right-hand corner to grow and resize windows, rather than stretching them from the top borders. He also suggested supporting window split panes and fundamentally rethinking how documents moved within a view. Tesler disliked the existing scrolling implementation and proposed placing directional arrows directly at the scroll bar’s top and bottom endpoints, a design he promptly prototyped.
This design closely resembled the Xerox Star, placing Tesler and other Xerox veterans at Apple in an awkward bind. Because they were bound by strict Xerox non-disclosure agreements, they were legally barred from telling Apple colleagues how the unreleased Star worked. Tesler explains: “Those of us who were from Xerox were under a confidentiality agreement that we weren't allowed to tell the other Apple people about the Star, and so as you go through this, you'll sometimes find that things seem like, isn't it an obvious solution, you could have got it from the Star? But none of us were able to say why this, how the Star was. We were only allowed to comment on other people's proposals and make new ones.” Star-like ideas gradually crept into Lisa discussions until Xerox publicly announced the Star in June 1981. Meanwhile, Tesler also pushed for an I-beam cursor for text selection instead of an arrow—drawing on a word processor he had built years earlier at Xerox—and urged expanding the cursor boundary from 16×16 pixels to 32×32.
- **Window resize control:** Proposed moving the grow box to the lower right-hand corner rather than manipulating the window header. - **Scroll controls:** Prototyped dedicated directional scroll arrows at the top and bottom of the scroll bar track. - **Text cursor:** Replaced the generic arrow with an I-beam pointer for text selection. - **Cursor size:** Recommended increasing hardware/software cursor dimensions from 16×16 to 32×32 pixels.
---
[33:32](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2012s) Rethinking Menus and Marketing's Pushback
By August 18, 1980, Tesler turned his attention toward the placement and behavior of application menus. At the time, the Lisa system behaved similarly to what Microsoft Windows later popularized: each individual window carried its own dedicated menu bar. Tesler submitted a radical counter-proposal: experiment with moving menus to the top or right border of the window, or detach them altogether into a full-width system bar running across the top of the physical screen. Furthermore, recognizing that hierarchical command structures might be unavoidable, he argued that navigating them should rely on direct mouse selection rather than requiring users to memorize long sequences of typed keystrokes.
Barry Smith from Product Marketing responded around the same time. Bill Atkinson had recently shifted the primary editing commands—Cut, Copy, and Paste—from the bottom of the window frame up toward the top, a change Smith praised enthusiastically. However, Smith wondered what would happen if a menu accumulated too many entries, asking whether menus should be permitted to scroll. Tesler resisted the idea vigorously: “Those of you who know the history of the Mac user interface know that at some point, I don't know, 1990 or so, we start adding scrolling to Mac menus, but we didn't have them in the early Mac or in the Lisa, and I was against it because that would have encouraged people to have a lot of menu items and I didn't think they should.” Smith also hated typing multi-key sequences to drill into command hierarchies, favoring single-stroke shortcuts regardless of tree depth, and agreed that the two-button mouse was far too confusing for ordinary users.
---
[35:19](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2119s) The One-Button Mouse Crusade and Shift-Click Selection
Following heated debates, Larry Tesler and Bill Atkinson joined forces on August 18, 1980, drafting a joint memo to convince management to eliminate the second mouse button entirely. An anonymous reviewer penned skeptical margins on their memo, but Trip Hawkins, the product marketing manager (who later founded Electronic Arts and 3DO), loved the idea. Hawkins insisted that Apple had to cater to everyday consumers rather than academic computer scientists: “Trip Hawkins, who later went on to found Electronic Arts and 3DO, was the product marketing manager, he loved it. He said, 'That's what we got to do, we got to think more in a consumer-oriented, really simple, get rid of all this, you know, computer science concepts and give people something real simple.'”
Removing the second button created an immediate technical challenge: extending text selections over long distances. While dragging worked well for short spans, dragging across a three-page document was tedious and error-prone. To solve this, Atkinson and Tesler introduced the keyboard modifier rule: users clicked the start of a selection, scrolled to the destination, and held down the Shift key while clicking the end. They argued the single-button design was fundamentally superior on three counts:
1. **Human Factors:** Eliminating button confusion meant developers did not have to invent and document arbitrary names for multiple buttons when trying to ship within six months. 2. **Manufacturing Cost:** Removing the secondary mechanical microswitch lowered physical production costs per unit. 3. **Future Hardware Compatibility:** Tesler foresaw alternative input devices: “Someday when we start having other things than mice on our computers, like joysticks for games, tablets, touchscreens, we'll be glad we only had one button because that one finger, or whatever, or pen that the user is using is the button.”
```mermaid flowchart TD accTitle: Selection Workflow on a One-Button Mouse accDescr: Step-by-step process of selecting long text spans using mouse clicks and keyboard modifiers.
subgraph Input["User Actions"] A["Click at start of text selection"] B["Scroll down document view"] C["Hold Shift key & click at target end"] end
subgraph System["System Response"] D["Anchor selection point"] E["Update visible page without dropping anchor"] F["Highlight full range between initial click and Shift-click"] end
A --> D D --> B B --> E E --> C C --> F ```
---
[37:41](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2261s) August 22, 1980: Dim Highlighting, Shortcuts, and Window Anatomy
On August 22, 1980, the team released a revised user interface specification with a mandatory three-day turnaround for comments, operating under the optimistic belief that after a month of design work, the specification was essentially complete. This draft introduced "dim highlighting" (graying out inactive menu options) for the first time. Rather than making unavailable commands disappear, the interface rendered them in muted gray text. Initially, the team permitted users to click them anyway (without triggering an action) and attempted to reuse dimming to indicate toggle states. Tesler quipped: “It was Occam's razor, one mechanism will do, they don't have to—well, turned out that one didn't do, so we had to apologize to Occam,” noting that check marks were eventually introduced to resolve user confusion.
```mermaid flowchart LR accTitle: Evolution of Disabled and Toggle Menu States accDescr: How Apple moved from overloaded dim highlighting to distinct check marks and grayed-out items.
subgraph Initial["August 1980 Draft (Overloaded)"] A1["Inactive Command"] --> B1["Dim / Grayed Out (Still clickable)"] A2["Toggled Setting State"] --> B1 end
subgraph Final["Eventual Resolution"] C1["Inactive Command"] --> D1["Grayed Out (Disabled)"] C2["Active Toggle Setting"] --> D2["Check Mark Indicator (✓)"] end ```
The team also standardized keyboard shortcuts for core application commands like Cut, Copy, Paste, and Undo, reserving keystrokes that third-party developers could not override. Although the early layout assigned the keys differently, they eventually arrived at the bottom-row sequence: - **Z:** Selected for **Undo** because it was on the far left, right under the hand for a frequent recovery action. - **X:** Chosen for **Cut** because it resembled a cross-out mark. - **C:** Chosen for **Copy** because of its natural mnemonic letter match. - **V:** Chosen for **Paste** because it resembled an inverted proofreader's insertion caret pointing down into the text.
The window anatomy diagram solidified several major user interface breakthroughs. Moving the menu bar to the top of the window allowed Atkinson to abandon UCSD Pascal-style replacing menus and utilize the vertical axis: menus pulled down over the document content. The vertical scrollbar runner was dubbed the "elevator shaft" and the scroll box was renamed the "thumb" instead of the "elevator," because it needed to support both vertical and horizontal axes. Finally, the window incorporated continuous scrolling arrows, though with one major difference from modern systems: in this 1980 draft, clicking an arrow pointed upward caused the document text itself to move in the arrow's visual direction rather than moving the viewport window downward.
- **Shortcut Layout Debate:** The team spent hours arguing over whether shortcuts should match keyboard position (`Z-X-C-V`) or menu order (`Cut, Paste, Copy, Undo`). - **Menu Hierarchy:** Pull-down menus successfully supported two levels of depth, leaving unresolved questions about how to handle tertiary flyout menus. - **Scroll Direction Inversion:** Clicking scrollbar arrows originally panned the canvas directly in the arrow's orientation, rather than shifting the viewport relative to the document.
[41:22](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2482s) Window Mechanics and the Dilemma of Per-Window Menus
In August 1980, the team worked through early window behaviors on the Lisa. Because they had active folders, they naturally had to define passive folders to represent whichever folder was inactive. Tesler points out an interface concept at the bottom of the screen that looks remarkably familiar: dragging a window down until it collapsed into a tab, which could then be clicked to slide back open. Tesler jokes that this exact behavior was originally designed for Lisa in August 1980 and “only took 17 years to implement” when it finally shipped in Mac OS 8. Microsoft introduced a somewhat similar concept in between, though with notable differences.
```mermaid flowchart TD accTitle: Evolution of Lisa Menu Placement accDescr: Diagram showing the transition from window-attached menus to the unified top-of-screen menu bar.
subgraph PerWindow["Per-Window Menus (Summer 1980)"] W1["Window Too Narrow"] --> M1["Menu sticks out to left or right"] W2["Window Near Screen Bottom"] --> M2["Menu overlaps off-screen bounds"] W3["Complex Sub-commands"] --> M3["Dialog boxes cover menu and window content"] end
subgraph TopBar["Top-of-Screen Menu Bar (Sept 22, 1980)"] TB["Unified Screen-Top Bar"] --> F1["No clipping or wrapping on narrow windows"] TB --> F2["Consistent position for dialog boxes"] TB --> F3["Keyboard Command Keys bypass long mouse travel"] TB --> F4["Dedicated space for global commands"] end
PerWindow -->|"Bill Atkinson's all-nighter"| TopBar ```
The major design crisis lay in what happened when an application window was narrow. Bill Atkinson drew out all the pathological edge cases: if a window was too narrow, the menu bar inside the window would not fit and would stick out past the right edge. If the window was pushed against the right border of the screen, the menu would awkwardly jut out to the left instead. If the window sat near the bottom of the screen, the pull-down menus had nowhere to drop. Tesler and the group hated these clumsy visual artifacts, but they also rejected the alternative of wrapping commands into a two-lane menu—a solution Microsoft later adopted in early versions of Windows.
The standard cadence of the Lisa UI group relied on Bill Atkinson pulling marathon programming sessions. Atkinson would spend all night coding prototypes, and the rest of the team would spend the next day testing and arguing over the build. As Tesler recalls: > “I don't know when he slept actually did he sleep and then he would do it again every night.”
[43:00](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2580s) Dissent from Publications: Gail Pilkington's Critique
The writers preparing the user manuals played an essential role in testing and critiquing the user interface, led by Gail Pilkington from the publications group. Pilkington, who had previously worked at Xerox, wrote a strongly worded memo taking aim at the team's emerging ideas. She disliked pull-down menus entirely, arguing that they were ugly and inherently destructive because they masked the work surface: a user would attempt to cut an object, only for the dropping menu to physically obscure the very text or graphic they wanted to cut.
Pilkington was equally critical of Atkinson's interactive scrubbing feature, which allowed a user to drag the mouse continuously across the menu bar to pop open each menu sequentially. While the software team celebrated this as a breakthrough that let users discover every command in one swift motion, Pilkington disliked having to scrub across menus just to see what the system could do. She also took issue with dimming unavailable items, proposing instead that inactive commands should simply be hidden. Reflecting on the constant debates within Apple, Tesler notes: > “I just chose that because there's a memo that I had an illustrative of dozens of people who had to send over every issue nothing specific about Gail in particular she said you know last version of the spec I thought we only had one issue which was when the menu when that little menu bar at the bottom was full we didn't know what to do about it and you should have just solved that instead of moving it to another place adding dropdowns and all these other things you over designed to solve the problem and besides they don't like X you know Z for cut next for a paste she had her own proposal that was Nimonic.”
- Gail Pilkington argued that pull-down menus obscured the user's active context. - Dragging along the menu bar to preview menus was seen by engineering as instant discoverability, but publications saw it as an annoying chore. - Debates raged over dimming unavailable items versus suppressing (hiding) them outright. - Disagreements extended down to keyboard shortcuts, where standard single-key actions clashed with proposals for strictly mnemonic key bindings.
[44:41](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2681s) September 22, 1980: Atkinson's All-Night Invention of the Screen-Top Menu Bar
Approximately one month after Tesler first suggested moving the menu bar to the top of the physical screen, Atkinson had another breakthrough night. On September 22, 1980, Atkinson showed up with the entire menu bar mechanism implemented at the very top of the desktop screen, complete with command-key shortcuts and checkmarks alongside active states. What Tesler had viewed merely as a convenient spatial repository for existing widgets was expanded by Atkinson into a comprehensive interaction framework.
Atkinson wrote a memo acknowledging the trade-offs of the design. The obvious downside was Fitts's Law travel distance: the user had to drag the cursor significantly farther to reach the top edge than to click a local window border. To counteract that latency, Atkinson implemented single-stroke command keys on the keyboard so experienced users could bypass the trip entirely. Another acknowledged issue was ambiguity: when many overlapping windows sat on the desktop, users might lose track of which window the top menu bar currently applied to—a limitation Tesler notes remains true to this day.
Despite those costs, the screen-top menu solved massive visual and architectural problems. It completely eliminated the clipping bugs of narrow windows sticking out over empty space. Dialog boxes triggered by parameterized commands could now appear in a predictable, standardized location directly beneath the menu bar without overlapping window content. Crucially, it provided a natural home for global system commands—such as system shutdown—that previously had no place to live when menus were confined to individual application windows, while simultaneously freeing up window headers for wider title tabs.
[46:44](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2804s) User Testing Discipline and "Bring Me The..."
By February 1981, schedule pressure began mounting. While the systems team was still designing the underlying operating system, the applications group—which Tesler managed—was blamed for holding up the schedule. Amidst this tension, Tesler set up a rigorous user-testing program and authored formal guidelines to rein in software engineers when observing real subjects.
Engineers frequently struggled to remain silent observers. When a test subject hesitated or got stuck, an engineer sitting in the back of the room would routinely jump up, sprint across the room, grab the subject's hand, and insist, "It's easy, you just do this!" Tesler established firm ground rules: observers were banned from arguing with one another in the room, patronizing the subject, or volunteering clues. When debates between engineers escalated, Tesler told them: > “Never argue with each other in front of the interviewee after they leave you can shoot each other doesn't matter but now well the not while the subjects there don't patronize a subject don't show off your knowledge.”
The tests regularly humbled the team. Engineers often brought in users specifically to settle an internal technical dispute and prove that their own interface was right, only for the participant to fail completely at both implementations, demonstrating that both engineers were wrong. In many instances, an unsophisticated user would casually ask why the feature didn't simply work in an obvious, alternate way, leaving the developers sheepishly agreeing to redesign it. Tesler also discovered a naming trick during usability sessions: directly asking "What would you call this?" paralyzed participants because they felt pressured to invent formal computer terminology. Instead, Tesler learned to frame the prompt as a natural request: > “If someone were to bring you this if you wanted someone to bring you this what would you say bring me the and then people would come up with something it actually worked pretty well.”
[49:46](https://www.youtube.com/watch?v=OW-atKrg0T4&t=2986s) April 1981: UI Bureaucracy and Design by Council
By April 3, 1981, management panic over shipping dates reached a fever pitch. With the operating system architecture finally solidifying, management decided the fundamental problem was that software engineers were wasting valuable hours debating usability rather than churning out code. Management's solution was to strip UI authority from the programming team and centralize all user interface decisions into an administrative council.
The newly formed council consisted of five individuals representing distinct branches of the Lisa project: - The division controller from finance. - The vice president of sales, who spent most of his time traveling on airplanes. - The head of publications for the Lisa project. - The software group's lead system architect. - A representative from product marketing.
While Tesler appreciated that the council formalized a structured issue-escalation workflow—forcing engineers to write up their arguments and get back to programming rather than burning eight hours arguing in the halls—the underlying governance model left him cynical. Tesler sums up the absurdity of deciding fine-grained human-computer interaction details through administrative committee votes: > “The council will rule by majority vote so I think what a way to design a user interface by majority vote of the controller the sales VP okay.”
[51:04](https://www.youtube.com/watch?v=OW-atKrg0T4&t=3064s) Establishing Rapid, Cheaper User Testing for the Lisa Filer
Frustrated by UI decisions being settled by committee votes, Larry Tesler and his colleagues sought an empirical antidote: “we thought well maybe we can overwhelm them with facts and that'll overcome this reliance on on votes of committees.” Chris Espinosa, Chris Dewar, and Wallis Judd (who Tesler believes may have previously worked at Xerox) became heavily involved in testing the Filer—the direct ancestor of the Macintosh Finder. Early test sessions quickly surfaced fundamental interaction problems, including the clear realization that users needed a method to select and manipulate multiple items at once, even before desktop items were formally represented as icons.
Dewar and Judd also reshaped Apple's testing methodology itself. Up to that point, testing typically followed a painfully slow and bloated path: companies would hire an outside testing agency at high cost, wait three months for a thick report, make software tweaks, and repeat the loop. Alternatively, evaluators would hand a subject an enormous manual, instruct them to read through it, videotape the grueling ordeal, and study the tape afterward. Instead, Dewar found immense value in a far simpler, informal approach: sitting right next to the user and fostering an active dialogue where the subject spoke aloud about what they were thinking and doing. Apple quickly embraced this cheaper, faster paradigm. Sessions were tape-recorded for later analysis, though early observers in the room had a bad habit of making too much background noise on the tapes, forcing the team to institute strict quiet policies for spectators.
```mermaid flowchart LR accTitle: Evolution of User Testing Methodology accDescr: Shift from traditional high cost testing to direct rapid testing on Lisa
subgraph Old["Traditional Industry Approach"] A["Hire Expensive Test Agency"] --> B["Wait 3 Months for Report"] B --> C["Heavy Manual Reading & Video"] end
subgraph New["New Apple Paradigm"] D["Sit Next to Participant"] --> E["Prompt Active Dialogue"] E --> F["Tape Record & Analyze Errors"] end
Old -.->|"Replaced by"| New ```
[52:55](https://www.youtube.com/watch?v=OW-atKrg0T4&t=3175s) New-Hire Guinea Pigs, Civilized Schedules, and the Lisa Checklist
A recurring criticism raised by Chris Dewar was that Apple was exclusively testing its own workforce. To find subjects with genuinely zero computer exposure, the team intercepted new hires during orientation on their very first day on the job. The orientation leader would present them with a choice: report immediately to their actual work assignments, or volunteer for a few hours as user test subjects. Most eagerly chose testing as an easy way to avoid work on day one. Because computer experience was exceptionally rare in the general workforce at the turn of the decade, these fresh employees made perfect surrogates for novice consumers.
Rather than the frantic two-subjects-per-hour pace attempted in earlier Xerox or Apple trials, the team established a disciplined, “civilized” schedule: one person at a time, three sessions a day (at 9:00 AM, 1:00 PM, and 3:00 PM), allowing about an hour per subject. Tesler emphasized the absolute necessity of maintaining a rigorous pre- and post-session checklist to manage testing overhead and maintain lab hygiene: - Verify coffee is made and ready for the participant. - Ensure blank evaluation questionnaires and cue cards are laid out in the testing room. - Rewind the audio tape recorder before the subject sits down. - Reboot the computer so the session does not inherit an unstable state or system crash. - Double-check secrecy protocols: after every evening session, physically cover the Lisa prototype and draw the room's window blinds so passersby outside could not peer in at Apple's unannounced machine.
[54:35](https://www.youtube.com/watch?v=OW-atKrg0T4&t=3275s) Testing LisaDraw and the Mystery of "Undo Last Command"
When Wallis Judd compiled his testing reports, he observed that several fundamental conceptual primitives bewildered beginners. Chief among them was the "Undo Last Command" function. Out of the subject cohort, seven individuals struggled to grasp what it even did, having never encountered software capable of reversing an action. Other commands elicited hesitation, specifically "Print a Copy" and "Mail a Copy." As Tesler noted, this confusion was entirely pragmatic: the prototypes had no attached printers and the system had no functional electronic mail capabilities whatsoever. Users could not build a mental model for operations that produced no tangible outcome.
Similar rigorous studies were launched for the graphics editor, LisaDraw (which was authored by Mark Cutter and later ported by him to the Mac as MacDraw). The UI team fretted over visual clutter and cognitive overload: could a user handle simultaneous rulers and crosshairs, or were there too many widgets crowding the canvas? Tesler joked that given modern applications like Adobe Photoshop, their early worries seem quaint, but in 1981 there was serious concern that ordinary people would avoid graphics software entirely under the belief that “most people can't draw so they wouldn't use a graphics program.” Tesler and his team combed through the session audio tapes to log every single mistake:
- Counted error frequencies precisely to calculate objective user error rates. - Tested how users reacted to onscreen coordinate aids, crosshairs, and rulers. - Aimed to replace committee opinions with scientific human factors data, even as the project schedule stretched past the one-year mark without shipping.
[56:26](https://www.youtube.com/watch?v=OW-atKrg0T4&t=3386s) The Battle with Marketing Over Arrow Direction and "Folders"
By June 1981, project management tension reached a boiling point. Pat Marriott circulated a formal memo on validating UI prototypes, pushing for definitive resolutions on lingering interface questions. Product marketing lead Trip Hawkins had reached his limit with endless design debates: “Trip Hawkins at this point is at his wit's end he says aren't we done with all these decisions yet let's get on with it why are we still talking.”
One prominent debate centered on window scroll arrows: should the arrow icons point away from each other or toward each other? Because scrolling downward caused the document text to move upward in the viewport—the opposite direction of the scroll intent—some argued the arrows should point inward. Tesler, however, refused to treat this as urgent, annotating the memo that testing could wait until September: “I wasn't in sync with product marketing who wanted all the decisions to be made because I knew that changing this was a matter of you know about three minutes of programming so what was the hurry I'd rather work on harder issues like you know getting the software to fit in memory or something.” Tesler also noted a naming convention of the era that often confuses modern observers: in 1981, Apple referred to all windows as "folders," meaning every open text or graphics document window on screen was technically called a folder.
[57:50](https://www.youtube.com/watch?v=OW-atKrg0T4&t=3470s) Blind Out-of-House Testing in Daly City: The Out-of-Box Experience
In October 1981, Apple yielded to Chris Dewar’s persistent urging and funded genuine outside testing. They rented a facility equipped with a one-way mirror in Daly City, California, recruiting 24 external participants who did not work for Apple and had no idea which company had built the hardware. The human factors specialists finally got to run a proper blind study to evaluate the critical "out-of-box experience"—whether a total novice could open the shipping box, read the manual, connect the hardware cables, and boot the machine without human assistance.
The results proved remarkably positive: - Subjects took an average of just 10 minutes from cutting open the box to having the system fully assembled and operational. - Two-thirds of the participants reported feeling comfortable using the system immediately after their first try. - Half of the remaining one-third who felt uncomfortable had been tripped up by software crashes during their run, skewing their perception while trying to race the clock. - Post-test questionnaires confirmed that users found the physical setup far easier in reality than they had anticipated before starting.
Tesler recalled that Apple maintained this low setup threshold initially on the Macintosh, but setup complexity steadily degraded over successive hardware iterations until the out-of-box setup time drifted toward an hour. That regression eventually prompted Apple executive Jean-Louis Gassée to demand new rounds of human factors testing, successfully hammering the setup time back down to ten minutes.
[59:41](https://www.youtube.com/watch?v=OW-atKrg0T4&t=3581s) The Xerox Star Announcement and Interface Governance
Around the summer of 1981, the competitive landscape shifted dramatically when Xerox officially unveiled the 8010 Star Information System at the National Computer Conference (NCC) in June. Key members of the Lisa team, including Bill Atkinson and possibly Steve Jobs, traveled to the conference to inspect Xerox's commercialized GUI firsthand. Back in Cupertino, Apple continued expanding its training and documentation staff, hiring Greg Stikeleather to work under Ellen Nold in the Lisa training department (Tesler noted that Stikeleather later became a successful software entrepreneur).
Internal governance shifted alongside these product milestones. The old User Interface Council, which had attempted to decide interface specs by straight majority vote, had essentially withered away without convening regular meetings. In its place, inspired by an outside management consulting seminar the team had attended, Apple instituted a formal responsibility assignment framework (an early form of a RACI matrix). This system classified personnel into specific roles: those with Authority, those with Responsibility, those Consulted, and those simply Informed. Because Ellen Nold’s training group fell under Product Management, marketing secured primary operational authority over user validation procedures.
[01:00:58](https://www.youtube.com/watch?v=OW-atKrg0T4&t=3658s) Winning Over Product Marketing with LisaDraw
By February 1982, about a year and a half into the Lisa user testing effort, the evaluation process had matured into a formal engineering discipline. Instead of casually running into Steve Jobs in the hallway after an ad-hoc session to recount what happened, the team relied on standardized forms and detailed write-ups documenting exactly what users did, how they executed tasks, and where they faltered. When testing users on drawing organizational charts, Larry Tesler did not yet have a working graphics printing pipeline, forcing him to draw mock org charts using the word processor. However, the application being tested was LisaDraw, written by Mark Cutter, which ended up playing a decisive political role inside Apple.
To overcome deep skepticism from product management, Tesler instructed Cutter to focus strictly on stability over new features: “I had Mark Cutter just try to get it really reliable and don't worry about too many features and then we gave all the product marketing people a Lisa, some temporary operating system, and the drawing program, that's it.” Operating on that early single-tasking OS, marketing staff began using LisaDraw to make presentation foils, text boxes, and office floor plans. The program's reliability won them over completely; complaints began dying down, and product marketing developed genuine trust that the engineering team knew what they were doing.
In one formal test run by Greg Stikeleather and Tesler, the team observed subtle interaction flaws that required immediate architectural fixes. When users began typing, the text selection i-beam cursor stayed stationary on the screen, obscuring the characters being entered. Stikeleather suggested making the cursor disappear during typing—a feature that did not yet exist in the underlying windowing system, but was promptly engineered. Another test exposed an issue with Cutter’s initial resize handles: Cutter had originally studded the perimeter of graphic objects at every fourth pixel, creating a dense, bead-like outline resembling a necklace that thoroughly confused users. Tesler recommended stripping those down to just eight standard manipulation points—the four corners and the four mid-sides—which became the canonical interaction pattern for object manipulation.
- User test documentation shifted from informal verbal reports to formal multi-page standardized write-ups. - LisaDraw was intentionally frozen on features to guarantee rock-solid stability for internal business users. - Product marketing adopted LisaDraw to generate foils (overhead transparencies) and room floor plans, quelling internal opposition to the Lisa project. - Object stretch handles were simplified from a continuous pixel necklace down to eight handles (four corners and four sides).
---
[01:04:14](https://www.youtube.com/watch?v=OW-atKrg0T4&t=3854s) Developmental Testing and the Terminology Project
By May 1982, the methodology expanded into what Greg Stikeleather categorized as "development testing"—testing software while it was actively being shaped rather than running evaluative human-factors tests post-mortem. Tesler personally conducted extensive training sessions, teaching thirty Apple employees over several weeks across different applications. By this juncture, data-driven user testing had supplanted internal corporate posturing; as Tesler put it, “By this time people were accepting this as a good approach because it was a lot better to be informed by a user test than to just see who talked the loudest in an argument, who had the most political clout.”
The training sessions revealed that user comprehension depended heavily on presentation and vocabulary: introducing identical UI mechanics using different metaphors or phrasing produced vastly different error rates. This insight triggered a comprehensive "Terminology Project" led by Ellen Nold. Nold ran extensive linguistic analyses, user tests, and cross-functional debates to standardize system vocabulary, establishing fundamental conventions like the "File" and "Edit" menus, along with standard command names. Roughly 95% of the terminology established in Nold's project transitioned directly into the Macintosh, and the vast majority subsequently carried over into Microsoft Windows.
At the same time, the realities of shipping loomed over the team. Although developmental testing continued to surface dozens of desirable refinements, the schedule left room for only one subsequent release. Tesler authored a thirty-page memo cataloging necessary user interface adjustments, prioritizing each issue by measuring its precise impact on the schedule: “I think by this time people were really realizing that our only differentiation was ease of use and it better be really easy.”
```mermaid flowchart TD accTitle: Developmental User Testing and Terminology Standardization accDescr: Flow showing how developmental user testing informed terminology and scheduling priorities for the Apple Lisa. subgraph Testing["Developmental Testing"] A["Teach 30 Apple Employees Across Apps"] --> B["Identify Terminology Gaps & High Error Rates"] end subgraph Terminology["Terminology Project (Ellen Nold)"] B --> C["Linguistic Analysis & Vocabulary Debate"] C --> D["Standardize Menus & Commands<br/>('File', 'Edit', Cut, Copy, Paste)"] end subgraph Production["Production Prioritization"] D --> E["30-Page UI Refinement Memo"] E --> F["Measure Schedule Impact vs. Usability"] F --> G["Ship Foundation to Lisa, Mac & Windows"] end ```
- Greg Stikeleather established clear differentiation between development testing (in-flight UX iterations) and traditional post-development validation. - The Ellen Nold terminology project formalized ubiquitous interface primitives, including the universal "File" and "Edit" menu structures. - User interface changes were strictly triaged against ship deadlines; changes had to justify their delay cost against product usability benefits.
---
[01:06:09](https://www.youtube.com/watch?v=OW-atKrg0T4&t=3969s) Cursor Behaviors and Desktop Icon Envy
Tesler’s detailed usability critiques addressed widespread micro-interaction inconsistencies across the Lisa software. Cursors changed shapes too erratically depending on where the pointer traveled within a window, prompting Tesler to urge substantial simplification. Double- and triple-click intervals were fixed in the code, penalizing users with varying manual dexterity; Tesler proposed introducing a user preference setting to adjust mouse double-click speed, which became the permanent foundation for the standard Apple mouse control panel. Another issue involved the busy wait indicator: Xerox PARC had used an hourglass cursor for long operations, and Lisa adopted a similar mechanism. Initially, the system waited a set duration before switching to the hourglass, but operations often finished just as the icon finally appeared, while some apps failed to show it at all. The software team had to invent a centralized algorithm to display and clear the wait cursor automatically.
The most dramatic interface disruption occurred when the Xerox Star was released commercially. Official management guidance commanded the Lisa team to ignore the Star to protect their ship date. However, internal morale buckled under an undeniable design realization: “There was icon envy, that was very serious, and we weren't allowed to work on it.” Coveting the Star's desktop metaphors, a rogue faction of Lisa engineers spent weekends coding an "iconic filer" secretly at home. When they finally revealed their working implementation to the company, it caused intense institutional friction over late-stage architectural thrash. However, because the code was already functional and the user manual author insisted the iconic model would not delay documentation, management could not kill it on schedule grounds alone.
To settle the impasse, Tesler brokered a compromise with product manager Trip Hawkins and engineering director Wayne Rosing: run empirical user tests comparing the existing list-based file manager (similar to a search utility) against the new icon-based desktop, letting users decide the outcome. When the results were tallied, both paradigms scored identically in learnability, raw performance, and error rates. The final decision came down purely to emotional appeal: when asked which interface they preferred, subjects overwhelmingly chose the iconic system. Reflecting on the turning point, Tesler observed: “And so we made a decision that had nothing to do—nothing to do with ease of use, nothing to do with ease of learning, nothing to do with error rate, it wasn't a human factors decision at all in the traditional sense, it was a decision based on what customers liked.”
- Cursor proliferation was reined in, and dynamic cursor suppression (hiding the i-beam while actively typing) was permanently integrated. - The customizable mouse click threshold was conceptualized and documented to accommodate differences in user motor skills. - The busy cursor (hourglass/clock) was re-architected with automated timing logic after early manual implementations proved out-of-sync with background tasks. - Underground weekend development by engineers created the Lisa Desktop Manager (iconic filer) in direct defiance of management directives. - Objective user testing proved icons offered no statistical superiority in speed or error avoidance over list-based filers; the desktop icon metaphor was adopted exclusively because end users preferred it visually.
[01:10:00](https://www.youtube.com/watch?v=OW-atKrg0T4&t=4200s) Larry Tesler’s Closing Remarks and Early Lisa User Test Video
Concluding his presentation, Larry Tesler mentions that certain elements originated from IBM rather than Xerox Star, remarking that he will not delve into that extensive background because audience members can consult the proceedings of the *Apple Computer, Inc. v. Microsoft Corp.* lawsuit to learn the full history. His final slide displays a September 1982 memorandum copied to Chris Espinosa, who was working in the Macintosh group at the time. Tesler explains that the Macintosh team had originally pursued an entirely different user interface before deciding they should adopt a subset of the Lisa user interface instead. As they designed their UI, the Mac team sought ideas from the Lisa group, prompting the Lisa team to begin copying them on internal design memos.
Before stepping down, Tesler plays a brief, 30-second archival videotape from July 1980 capturing one of the earliest Lisa user tests. He and Bill Atkinson took turns conducting these sessions; this clip features Atkinson working with an unseen female test subject. Although most of the footage shows only the out-of-focus back of Atkinson’s head, Tesler points out a fleeting view of the Lisa display. The monitor shows an early interface variant with a menu positioned across the bottom of the window and a highlighted selection made with the mouse. Tesler observes that Atkinson had explained something simple that the subject failed to understand, forcing him to restart the explanation. Tesler then closes his section of the lecture and turns the floor over to Chris Espinosa.
[01:12:55](https://www.youtube.com/watch?v=OW-atKrg0T4&t=4375s) The Divergent Roots of the Apple II and Lisa/Mac User Interfaces
Chris Espinosa opens by describing how the Macintosh human interface effort dovetailed with the remarkably productive period of Lisa UI design in the summer of 1982, marveling at how a few intensive months established interface patterns that persisted in both the Macintosh and Microsoft Windows. He notes, however, that when Tesler initially proposed delivering this lecture to educate engineers joining Apple through corporate acquisitions, many of the people and documents referenced had roots completely outside the graphical user interface. Instead, they belonged to a parallel user interface tradition developed within the Personal Computer Systems Division for the Apple II and Apple III.
This division operated in a distinct, triangular building located at the intersection of Interstate 280 and Lawrence Expressway—dubbed the "Bermuda Triangle" because it was where the Apple II team was supposedly sent to die. Espinosa explains that the crucial difference between the Lisa/Mac projects and the Apple II effort lay in organizational alignment. In Lisa and Macintosh, engineering teams directly initiated and drove usability improvements. In the Apple II division, usability work did not originate in engineering; rather, the pressure to make systems approachable came from the Publications Department, the Training Department, and teams creating retail store demonstrations. Their challenge was to mask the underlying complexity of an established software ecosystem that had accumulated since 1977 by applying cosmetic interface layers and introductory tutorials over legacy software.
```mermaid flowchart TD accTitle: Apple II versus Lisa and Mac UI Driving Forces accDescr: Diagram contrasting how usability was driven in the Lisa and Mac groups versus the Apple II division.
subgraph AppleII["Apple II Division (Bermuda Triangle)"] AII_Pub["Publications, Training & Retail Demos"] -->|"Mask complexity over legacy software"| AII_UI["Sugared Interfaces & Tutorials"] AII_Eng["Engineering / Legacy Base (1977 onward)"] -.->|"Separated from usability push"| AII_UI end
subgraph LisaMac["Lisa & Macintosh Groups"] LM_Eng["Core Engineering Teams"] -->|"Integrated directly from the start"| LM_UI["Unified Graphical User Interface"] end ```
- In the Lisa and Macintosh projects, engineering teams were the driving force behind ease of use. - In the Apple II division, usability was driven by the Publications, Training, and Retail Demonstration groups attempting to disguise underlying system complexity without breaking legacy compatibility. - The Apple II group was physically isolated in the black "Triangle Building" at Highway 280 and Lawrence Expressway.
[01:15:51](https://www.youtube.com/watch?v=OW-atKrg0T4&t=4551s) Bruce Tognazzini and the Evolution of the Interface Guidelines
Espinosa displays a document showing the revision history of the *Apple II Human Interface Guidelines*, tracing its development across several iterations before it merged into the Macintosh project:
- **First Draft (September 1978):** Written by Bruce Tognazzini ("Tog"). - **Second Draft (March 1979):** Revised by Tognazzini. - **Third Draft (Mid-1980):** Further developed text-based interface principles. - **Fourth Draft (Early 1981):** Co-authored by Tognazzini and Steve Smith. - **Macintosh Integration (Late 1982):** Espinosa took over the guidelines for the Mac group, integrating concepts developed during the Lisa project. - **Return to Apple II:** The guidelines later migrated back to cover the Apple II graphical user interface.
Espinosa recounts that Tognazzini entered the Apple community by running a computer retail store in San Francisco where the local Apple Core user group met. Having sold Apple II systems over the counter, Tognazzini possessed firsthand knowledge of the confusion everyday customers felt when confronting a personal computer for the first time. Upon joining Apple, he collaborated with J.D. Eisenberg to create *Apple Presents Apple*, an interactive disk tutorial designed for first-time buyers and in-store retail demonstrations.
[01:18:14](https://www.youtube.com/watch?v=OW-atKrg0T4&t=4694s) User Testing Methodology and the Color Monitor Dilemma
Reading aloud from Tognazzini’s writings on testing methodology, Espinosa illustrates how early Apple II software was evaluated on real novices:
> “Our testing method is as follows: we set up a room with five to six computer systems. We invite groups of five to six users at a time to try out the systems, often without knowing that it is the software rather than the system we are testing. We have two of the designers in the room; any less and they miss a lot of what's going on, any more, the users feel as though there's always someone breathing down their neck. The initial ground rules are that no questions will be answered, as by the time the formal testing begins, we can supply a draft of the manual. Usually by the second group, some glaring defects in the interface have shown up, and we have to give them help getting past the stumbling blocks. 95% of the stumbling blocks found are found by watching the body language of the users: watch for squinting eyes, hunched shoulders, shaking heads, and deep, heartfelt sighs. When a user hits a snag, he will assume it is his fault; he will not report it, he will hide it. Make notes of each problem and where it occurred. Question the users at the end of the session to explore why the problem occurred. You will often be surprised what the user thought the program was doing at the time he got lost.”
Espinosa then reads a case study from the development of *Apple Presents... Apple //e*, created by Tognazzini and Eisenberg to teach basic system operation to retail shoppers, students, and new owners. The authors had spent hours debating the most intricate instructions, yet the primary stumbling block turned out to be an apparently trivial opening question: determining whether the user was viewing a color display or a monochrome monitor. In classroom and retail environments, novices looking at a green monochrome screen frequently could not tell whether they had a monochrome monitor or a color television with its color turned off. The team's initial approach—displaying a graphic and asking “Is the picture above in color?”—resulted in an immediate 25 percent failure rate among test users.
[01:21:06](https://www.youtube.com/watch?v=OW-atKrg0T4&t=4866s) Testing the Color Prompt: Bruce Tognazzini’s Five Iterations
Continuing his reading from Bruce Tognazzini’s account of testing the Apple II interactive training disk, Chris Espinosa details the escalating comedy of trying to formulate a single foolproof screen prompt: determining whether the user was viewing the software on a color monitor or a monochrome display. In the first attempt, users on black-and-white sets assumed their color knob was simply turned down; rather than answering incorrectly, they turned around and asked the test proctor whether the monitor was color or not. Since Apple could not ship an author inside the box with every computer disk, a self-contained software test was mandatory.
For the second attempt, the team substituted a graphic showing words rendered in the Apple II’s four native vivid colors—green, blue, orange, and magenta—paired with the prompt: *“Are the words above in color?”* Color TV users failed at 0%, and black-and-white monitor users failed at 0%. However, green-screen monitor users registered a 100% failure rate, highlighting why hardware diversity in a test suite is indispensable. In the third attempt, the prompt was adjusted to: *“Are the words above in more than one color?”* Here, color TV users failed at 0%, black-and-white users failed at 16% (later admitting they chose the wrong answer deliberately), and green-screen users failed at 50%. The green-screen users logically reasoned that they were looking at both green and black—two distinct colors—and answered “yes.”
```mermaid flowchart TD accTitle: Evolution of the Apple II Color Detection Prompt accDescr: Iterations of the prompt used to detect color versus monochrome monitors and their failure modes.
subgraph Iterations["Prompt Iterations"] A["Attempt 2:<br/>'Are the words above in color?'"] B["Attempt 3:<br/>'Are the words above in more than one color?'"] C["Attempt 4:<br/>'Are the words above in several different colors?'"] D["Attempt 5:<br/>'Do the words above appear in several different colors?'"] end
subgraph Outcomes["Failure Modes & Results"] OA["100% fail on green screen<br/>(all green counted as color)"] OB["50% fail on green screen<br/>(saw green and black as 2 colors)"] OC["~20% skimmed grammar<br/>('green, red, etc. ARE colors')"] OD["0% failure across all displays<br/>(Success)"] end
A --> OA OA --> B B --> OB OB --> C C --> OC OC --> D D --> OD ```
By the fourth attempt, the prompt read: *“Are the words above in several different colors?”* The failure rate stubbornly hovered at 20% for black-and-white and 23% for green-screen displays. The authors were driven so crazy that they joked they would rather give away a free color monitor with every Apple II sale than keep debugging the phrasing. It turned out roughly one-fifth of users were misreading the syntax: they interpreted the line as an abstract knowledge query—agreeing that green, violet, and red are indeed several different colors—and simply pressed yes. Finally, the fifth attempt introduced an unambiguous perceptual verb: *“Do the words above appear in several different colors?”* The failure rate dropped to zero percent across all monitor configurations.
As Espinosa reads from Tognazzini's text to emphasize the broader moral: “It clearly exemplifies how even the most careful designers can totally miss when guessing at how users are going to respond.”
- The training application contained in excess of 100 KB of code—a massive engineering effort on a 128 KB machine—and this single color-detection screen was the only interface issue that required more than one correction.
---
[01:23:40](https://www.youtube.com/watch?v=OW-atKrg0T4&t=5020s) The File Card Metaphor, Deadlines, and the Roots of Consistency
Espinosa explains that the Apple II platform was not a single, cohesive project, but rather an evolving collection of projects. Software initially greeted users with basic square bracket or angle bracket prompts. By the era of the Apple IIe and the Apple III, engineers devised a spatial, text-based windowing interface known as the “file card metaphor.” By leveraging custom glyphs embedded within the character generator ROM, programs displayed stacked index cards reminiscent of the Lisa interface. Users pressed numbers 1 through 6 to choose menu items and pressed the Escape key to step backward through the navigation hierarchy. It formed a rigid, keyboard-driven spatial interface without a mouse, yet it established cross-application consistency across internal Apple releases and major third-party software, such as Quark Catalyst, the hard disk management utility from the creators of QuarkXPress.
This push toward strict interface consistency was not merely an aesthetic choice; it was driven by hard operational realities inside Apple. Espinosa’s mother ran the user training division, where interface consistency directly lowered instructional time and costs. Simultaneously, Espinosa ran Apple’s publications department, which faced unforgiving manufacturing timelines: in the days before desktop publishing, turning camera-ready film into bound manuals at the print shop required a mandatory six-week lead time.
Because user manuals had to be completed and sent to the printer months before the software was finished, writers could not wait for working builds. Instead, technical writers forced programmers to specify their human interfaces in advance. Holding programmers to standardized behavior across applications allowed the documentation team to write accurate manuals before code completion. Tognazzini’s pioneering work on the *Apple II Human Interface Guidelines* was born directly out of a publications style guide designed to standardize terminology and operational metaphors across user manuals.
Espinosa summarizes how external constraints enforced design discipline: “And by using consistent explanations that drove consistent design and in some of the applications, so that was some of the origins of user testing and of consistency of user interface design in the Apple II group.”
---
[01:27:08](https://www.youtube.com/watch?v=OW-atKrg0T4&t=5228s) Fusing Lisa with Apple II: The Macintosh Developer Battle
The interface philosophy of the Macintosh represented the fusion of two very different traditions within Apple. Larry Tesler’s Lisa group contributed years of rigorous laboratory user testing and sophisticated graphic user interface mechanisms inherited from Xerox PARC. However, the Lisa was envisioned as an appliance running a closed suite of only seven native applications. The Apple II team brought a grassroots, open platform mindset built to support an ecosystem of hundreds of independent software vendors. For the Macintosh, Apple grafted Lisa’s graphical desktop paradigm onto the developer-facing guideline discipline developed in the Apple II style guides.
This approach provoked immediate and intense pushback from the software development community between 1982 and 1983. Programmers were accustomed to writing directly to framebuffers and creating bespoke control schemes to distinguish their software. When Apple mandated the use of a shared Toolbox burned into ROM and insisted on uniform menus, dialogs, and window chrome, developers felt their creativity and competitive advantage were being erased.
Espinosa recounts the heated skepticism that Apple’s interface team encountered on the road: “I remember very, very, very clearly that one of the massive controversies around the development for the Macintosh circa 1982 to 1983 was developers would come up to us and say, ‘You know, if you make the user interface consistent and if you put all that software in ROM... how are we ever going to make our applications unique and stand out and be different from each other in the marketplace?’”
Only by pointing to empirical user testing data could Apple persuade developers that consistency was an asset rather than a liability. Standardized controls dramatically reduced the learning curve for new software, making customers far more willing to purchase and adopt a second or third Macintosh application if they already knew how the system worked.
---
[01:29:15](https://www.youtube.com/watch?v=OW-atKrg0T4&t=5355s) HyperCard in the Field: Testing Renault Mechanics in France
Fast-forwarding past the Mac’s initial launch years, Espinosa introduces a historical video tape sourced from the Apple corporate library documenting user research in industrial field settings. While early GUI testing occurred in sterile corporate labs, HyperCard introduced a free-form development environment that allowed completely non-standard software interfaces, generating an entirely new set of design dilemmas. To understand how non-traditional users interacted with customized HyperCard stacks, Apple researchers Laurie Vertelney and Kate Gomoll (identified with help from audience member Joy Mountford) traveled to France to observe auto mechanics using an electronic parts catalog system deployed at Renault dealerships.
The video footage highlights the stark contrast between pristine office design assumptions and the gritty reality of grease-stained repair shops. Researchers observed mechanics in their natural workflow, balancing paper order forms, greasy parts, and hefty multi-volume technical manuals while compiling estimates. The mechanics were interviewed on-site in French, and their physical manipulation of paper artifacts—such as keeping an estimate form physically perched on top of a catalog while flipping through diagrammatic indexes—provided critical insights into visual search, multitasking, and workflow anchoring. This observational data directly shaped Apple’s recommendations for search mechanisms, layout conventions, and tactile screen interactions in customized database applications.
[01:32:54](https://www.youtube.com/watch?v=OW-atKrg0T4&t=5574s) Usability Failure in the Electronic Documentation System
A videotaped usability test demonstrates the confusing hurdles users encountered in early software design. A test participant, tasked with solving a problem using an electronic documentation system after completing a paper-based test, spends nearly ten minutes merely attempting to inspect the system. To begin, the subject is instructed to click on an icon, but doing so triggers an instructional dialog box instead of opening the expected tool. The dialog instructs the user to press and hold down on the icon to reveal a pop-up menu, but the user misses the text explanation inside the box and becomes confused by messages flanking the interface.
```mermaid flowchart TD accTitle: Electronic Documentation Usability Breakdown accDescr: Flowchart illustrating the user's failed attempts to navigate the electronic documentation system.
subgraph Attempt1["First Attempt"] A["Click on icon"] --> B["Instructional dialog box appears"] B --> C["User misses text instructions"] C --> D["Clicks 'OK' to dismiss dialog"] end
subgraph Attempt2["Second Attempt"] D --> E["Clicks menu on left side of screen"] E --> F["No menu items function<br/>(Lacks vehicle identification)"] end
subgraph Attempt3["Third Attempt"] F --> G["Clicks icon again"] G --> H["Dialog box re-appears"] H --> I["User resorts to random clicking strategy"] end ```
After finally clicking "OK" to dismiss the dialog, the participant navigates to menus positioned on the left side of the screen. Unfortunately, none of the menu items work because the user has not yet entered the required vehicle identification needed to initiate an active work session. The user retreats to clicking on the original icon, which once again summons the unhelpful dialog box. Failing to realize that holding the mouse down over the icon is necessary to invoke the pop-up menu, the participant falls back on a trial-and-error strategy of clicking randomly across the screen.
[01:35:31](https://www.youtube.com/watch?v=OW-atKrg0T4&t=5731s) Eternal Lessons of User Testing and Bad Design
Chris Espinosa reflects on the demonstration tape, observing that it provides two timeless lessons: first, that bad design knows no bounds, and second, that a user interface is never truly finished or guaranteed to be right on the first try. He contrasts the early era of computing—when the market was entirely unsaturated and people had never seen a personal computer, a mouse, or a graphical screen—with the present day, where it is taken for granted that nearly everyone in Western society understands basic concepts like pointing, clicking, dragging, files, and printing. Espinosa jokes about how technical requirements have faded from consumer consciousness: “I still find it surprising that we don't talk about sectors and cylinders anymore on disks which was one of the main things we had to explain in 1978–1979 because there was some reason you needed to know that I forget why.”
Despite greater computer literacy among modern users, Espinosa emphasizes that testing assumptions remains an ongoing obligation for software designers: “Having to test new designs and test your assumptions of what your audience knows is pretty much eternal.” With the formal presentation running late, Espinosa and Larry Tesler open the floor to audience questions. Espinosa invites prominent members of Apple's human interface history who are sitting in the audience—including Joy Mountford and Annette Wagner—to chime in, correct them, or share differing viewpoints as Tesler passes the microphone around the room.
[01:37:37](https://www.youtube.com/watch?v=OW-atKrg0T4&t=5857s) Did Apple "Rip Off" Xerox PARC?
An audience member opens the Q&A by asking Larry Tesler to address the persistent claim that Apple simply stole its interface concepts from Xerox PARC, noting that while Jef Raskin had disputed that narrative, it remains a pervasive legend. Tesler confirms that Apple's earliest user interface prototypes were deliberately modeled on Smalltalk, sharing a visual aesthetic of overlapping windows, icons, and desktop metaphors. However, as the design progressed, Apple diverged significantly from the Xerox approach, introducing foundational elements such as placing a unified menu bar across the top of the entire screen.
Tesler points out that if one directly compares a Xerox Star or Smalltalk interface with the Apple Lisa or Macintosh, the behavioral and visual differences far outweigh the similarities: - **Direct manipulation and dragging:** The Xerox Star lacked the concept of dragging objects across the screen; moving items involved clicking one location, pressing a function key, and clicking the destination. - **Mouse controls:** Xerox systems used two- or three-button mice, whereas Apple committed to a single-button paradigm. - **Menu structures:** The Xerox Star did not have a global menu bar and only incorporated a single contextual menu late in its development cycle. - **Broad influences:** Beyond Xerox, Apple's interface drew inspiration from Hewlett-Packard systems, the UCSD Pascal environment, the Apple II, and late-1970s IBM research publications.
Summarizing the relationship, Tesler states: “I think the Xerox work had a lot to do with it, but usually when the—if you sat down to try to use a Star or Smalltalk, you would find that there were I think more differences than similarities in what you would actually see and do.”
[01:39:31](https://www.youtube.com/watch?v=OW-atKrg0T4&t=5971s) Designing for Novices versus Experts
Responding to an audience question about whether the Lisa team tested how users acculturated and advanced over time, Tesler explains that testing was almost exclusively focused on absolute novices. Because 95 percent of potential customers had never touched a computer, bringing external test subjects to high levels of expertise in a laboratory setting would have consumed prohibitive amounts of time. To observe expert workflows, the team used internal staff—such as Lisa product marketing personnel—who used the machines daily and reported bottlenecks, slow operations, and awkward interactions back to the engineers.
Chris Espinosa elaborates on the structural dilemma this dynamic created, one that persisted throughout the development of the Macintosh:
> “The constant tension is that the people who are designing are almost always by definition expert users and will often overlook that what they think is obvious is not at all obvious to a novice user.”
Espinosa explains that this tension leads to two potential software outcomes: - **The ideal design:** An interface that remains immediately approachable for a beginner while “gradually unfolding itself for the expert” through progressive disclosure and shortcut keys. - **The compromised design:** A “lukewarm mediocrity” that tries to appease both extremes simultaneously, ending up too convoluted for a novice to grasp yet not powerful or flexible enough to satisfy an experienced power user.
[01:41:38](https://www.youtube.com/watch?v=OW-atKrg0T4&t=6098s) Consultant Realities and the "Keyboard Mush" Test
An audience member and long-time colleague of Tesler comments on how easily engineering teams succumb to unexamined assumptions rather than seeking external validation. Speaking from consulting experience, the participant notes that clients expect software to match their specific organizational habits, requiring thorough design reviews before writing code.
The speaker then shares an anecdote from the West Coast Computer Faire in San Francisco, where Steve Jobs and Apple marketing staff were publicly showcasing the Lisa. The attendee and a colleague from Xerox had been browsing the exhibition floor, evaluating early workstations like the Fortune 32:16—one of the earliest available 16-bit Unix-based personal computers. The Fortune booth featured a glamorous display podium running Unix and CP/M-style software.
To evaluate system stability, the speaker's friend decided to execute a stress test they had discovered while building commercial software: the "keyboard mush" test. The test simply involves raking one's entire hand across the keyboard several times in quick succession to see whether the system's input buffer handles the barrage or crashes the software. When the colleague performed the test on the Fortune machine right beside the booth presenter, the computer instantly froze and died. Shaken by how quickly it broke, the pair crept over to the Apple booth to see Steve Jobs and the Lisa. While they agreed not to deliberately subject the Lisa to the destructive keyboard mush test, the attendee accidentally brushed against the upper-right corner of the Lisa keyboard while reaching across the table for a product brochure.
[01:44:12](https://www.youtube.com/watch?v=OW-atKrg0T4&t=6252s) The Danger of Unforeseen Network Failures and OOP Metaphors
An audience member recounts an anecdote from a computer demonstration show where networked Lisa machines completely crashed. Attempting to reboot one machine brought down every other workstation connected to the booth network, forcing staff into a full power cycle. Larry Tesler acknowledges the comment with a wry observation about planning for the unforeseen, while urging that audience questions stay brief due to time constraints.
```mermaid flowchart TD accTitle: Network Demonstration Failure accDescr: Diagram showing how a single failure during a Lisa network demo cascaded across all connected machines at a trade show booth.
subgraph Failure["Network Incident"] A["Single Lisa crashes during demo"] --> B["Reboot attempt fails"] B --> C["Network cascade: all booth machines crash"] end
subgraph Resolution["Hard Recovery"] C --> D["Complete system power cycle required"] end ```
Addressing a question regarding whether the user interface metaphors directly correspond to object-oriented programming (OOP), Tesler explains that the link was intentional from the beginning. In Smalltalk—one of the earliest object-oriented programming languages and graphical user interfaces—objects paired directly with generic commands capable of acting upon them. This conceptual architecture carried over into the Xerox Star and directly shaped the mindset of early Lisa developers, though Tesler cautions against treating the connection as dogma:
> “I’m just saying it the user interfaces that we were developing we had that in mind but that doesn't mean that a good user interface has to be object-oriented no.”
- Smalltalk explicitly paired language-level objects with generic interface commands. - Xerox Star pushed the object-action metaphor even further into its desktop environment. - The early GUI designers were steeped in OOP concepts, but Tesler notes that a successful user interface does not strictly require object-oriented foundations.
---
[01:46:17](https://www.youtube.com/watch?v=OW-atKrg0T4&t=6377s) Internal Tools: From PolyMorphic Poly-88s to UCSD Pascal
When asked what tools were used to write the historical memos and design documents shown throughout the presentation, Larry Tesler and Chris Espinosa reminisce about Apple's primitive pre-Mac infrastructure. Tesler notes he never owned an Apple III, relying instead on Apple Writer or the UCSD Pascal program editor running on an Apple II. Espinosa adds that power users relied on a command-line formatting pipeline: drafting within the UCSD Pascal text editor and processing files through an nroff-like utility called AppleScript (unrelated to the later scripting language) before sending them out to hardware printers.
Outputting physical copies involved loud Qume daisywheel printers when time and sound tolerances permitted, or standard 80-column dot matrix printers for draft passes. Before the Apple II and Apple III became standard internal office fixtures, Jef Raskin had introduced PolyMorphic Systems Poly-88 microcomputers, using their built-in screen editors as dedicated terminals across the team.
- Early specification memos were written in Apple Writer or the UCSD Pascal text editor on the Apple II. - Advanced document formatting relied on an internal nroff equivalent termed AppleScript. - Hard copies were output to noisy Qume letter-quality printers or 80-column dot matrix units. - Prior to wide Apple hardware adoption inside the company, Jef Raskin equipped the team with PolyMorphic Poly-88 machines for text entry.
---
[01:47:39](https://www.youtube.com/watch?v=OW-atKrg0T4&t=6459s) Legal Battles: GEM, Digital Research, HP NewWave, and Microsoft
Addressing an audience question about Digital Research's GEM (Graphics Environment Manager) desktop, Tesler details Apple's initial reaction to early GUI clones. GEM resembled the Macintosh interface so closely that Apple sent formal complaint letters, initiating inter-company negotiations. However, Apple abruptly shelved aggressive action against Digital Research when Microsoft and Hewlett-Packard emerged with Windows and NewWave.
Digital Research was struggling financially, and Apple was reluctant to be seen bullying an underdog. Shifting targets, Apple entered protracted copyright infringement litigation against the corporate giants instead. As Tesler dryly jokes about Apple’s legal priorities:
> “Digital Research at the time was kind of a struggling company and Apple didn’t want to you know basically pick on a little company so today we picked any two companies that were too big instead of picking on one that was too little.”
---
[01:48:41](https://www.youtube.com/watch?v=OW-atKrg0T4&t=6521s) The Integrated Suite Fallacy: Lisa Office System vs. Microsoft Office
The discussion shifts to why the Lisa project rejected third-party software in favor of a closed, bundled application suite. Tesler explains that both Xerox Star and Lisa teams operated under the assumption that end users only ever needed a handful of applications. While true in user behavior, assuming that system vendors could supply all those tools proved disastrous. Lisa management envisioned third parties only filling narrow vertical niches—one turnkey accounting package, one specialized layout tool—capping potential software offerings at 20 or 30 titles. This closed architecture was used internally to justify Lisa's existence alongside the Apple II and Apple III, marketing the integrated suite as a feature, which ultimately backfired.
Chris Espinosa defends the original intuition behind bundled software, noting that the entire software market in 1980–1981 was racing to build integrated application suites. Personal Software (later VisiCorp) attempted this with Visi On to expand VisiCalc into word processing and databases, while MicroPro pursued the same strategy with WordStar. Microsoft later validated the business thesis by turning Excel on the Macintosh into Microsoft Office, capturing the platform:
> “So office suites are certainly they certainly were not a dumb idea of 1981 that's something that has really monopolized the industry.”
Tesler concurs that while the Lisa was among the earliest bundled office suites and one of the first multitasking personal computers, it fundamentally missed the marketplace requirement: users required an affordable platform with snappy performance and a wide-open third-party ecosystem.
| Metric / Attribute | Apple Lisa Strategy (1981–1983) | Modern Suite Reality (Microsoft Office) | |:--- |:--- |:--- | | **Ecosystem Stance** | Closed; vendor-supplied suite with rare vertical 3rd-party add-ons | Broad, open OS platform; vendor dominates suite layer | | **Catalog Size** | Envisioned at roughly 20 to 30 titles maximum | Thousands of distinct applications running alongside core suite | | **Market Role** | Attempted to differentiate hardware from Apple II / III | Became the default business computing platform (Windows + Office) | | **Cost / Performance** | High hardware cost; sluggish multitasking overhead | Decoupled software licensing from commoditized personal computer hardware |
---
[01:52:24](https://www.youtube.com/watch?v=OW-atKrg0T4&t=6744s) The Three-Year-Old and MacSketch: Design vs. Acculturation
An audience member asks about testing interfaces on completely naive users versus modern users who bring years of cultural conditioning and familiarity with computers. Chris Espinosa counters with a personal user test conducted during Thanksgiving 1981. He brought a raw Macintosh prototype—housed in glued, square-cut Plexiglas panels before any injection-molded production cases existed—to his girlfriend's family home. Booting directly from floppy into Bill Atkinson's "MacSketch" (the precursor to MacPaint), with no Finder present, he handed the mouse to a three-year-old nephew:
> “That boy spent four hours drawing with MacSketch he learned it in no more than fifteen or twenty seconds just you know he pressed the button and draw things on the screen and he was drawing things with with an early version of MacPaint with virtually no tutoring and almost no language at all with no color with no acculturation at all.”
> “If you can appeal to a three-year-old and get a three-year-old with no language skills to learn how to do something productive in no time at all that's not a cultural statement you've done something right in design and that's when I knew we were really onto something.”
```mermaid flowchart LR accTitle: The 1981 Prototype MacSketch Test accDescr: Workflow showing the setup of the Plexiglas Macintosh prototype running MacSketch for a three-year-old user.
subgraph Hardware["Plexiglas Prototype (1981)"] A["Hand-cut Plexiglas case"] --- B["Raw internal circuitry"] end
subgraph System["Turnkey Software"] C["Single floppy boot"] --> D["MacSketch (Early MacPaint)"] D -.->|"No Finder / No OS layer"| E["Direct canvas input"] end
Hardware --> System System --> F["3-year-old draws for 4 hours with 15-second learning curve"] ```
Espinosa argues that while pure design can transcend culture, modern user acculturation has created liabilities. Modern developers have "gotten soft" and tolerate gratuitous interface complexity rather than laboring to eradicate it. Furthermore, ingrained user habits make UI evolution extraordinarily difficult. When Microsoft announced plans to shift desktop interaction from double clicks to single clicks in the late 1990s, pundits claimed Apple was being left behind. Espinosa maintained that users habituated over years could not simply abandon muscle memory. Microsoft was ultimately forced to backtrack on single-click desktop navigation in Windows updates because even two years of Windows 95 usage had cemented double-clicking habits across millions of people.
- The Thanksgiving 1981 Mac prototype ran MacSketch inside an improvised Plexiglas chassis with no injection-molded enclosure. - The interface required zero verbal coaching or written literacy for a three-year-old to master within 20 seconds. - Espinosa warns that industry designers no longer fear complexity the way Apple teams did in 1981. - Habitual acculturation proved so unyielding that Microsoft had to abandon mandatory single-clicking after consumer resistance.
[01:55:46](https://www.youtube.com/watch?v=OW-atKrg0T4&t=6946s) Acknowledging the Designers and Concluding the Session
As the lecture draws to a close, recognition is turned to several instrumental figures sitting in the audience who contributed directly to the creation of the user interfaces for the Apple Lisa and the Macintosh. The speaker calls on them to stand up and be recognized by the attendees, giving special praise to Annette Wagner for her foundational contributions to the original visual aesthetic, graphics, and typography of the Lisa: “Lisa and the Mac now maybe they could stand up, and Annette Wagner especially, who was worked on the original Lisa look and graphics and fonts and everything, and Joy and Bob, I mean, why don't you all stand up, all you Apple user interface people?”
Prompted by the host, members of the Apple Human Interface and design lineage—including Annette Wagner, Joy Mountford, and Bob Glass—stand to generous applause from the crowd. The host then invites the attendees to transition to an informal reception and continuation of the Q&A located nearby, announcing: “We're in a warehouse just down the street to the right, and Larry and Chris, would you walk through there to answer questions, right?” The event wraps up with a final round of applause honoring speakers Larry Tesler and Chris Espinosa as the audience prepares to continue conversations one-on-one.
- **Key Contributors Acknowledged:** - **Annette Wagner:** Recognized for her seminal work on the visual design, icons, fonts, and graphics of the Apple Lisa. - **Joy Mountford:** Longtime manager of Apple's Human Interface Group (HIG). - **Bob Glass:** Apple interface designer and early contributor.
## Notable quotes > [01:42:51](https://www.youtube.com/watch?v=OW-atKrg0T4&t=6171s) The constant tension is that the people who are designing are almost always by definition expert users and will often overlook that what they think is obvious is not at all obvious to a novice user. — Chris Espinosa
> [01:18:14](https://www.youtube.com/watch?v=OW-atKrg0T4&t=4694s) When a user hits a snag, he will assume it is his fault; he will not report it, he will hide it. — Bruce Tognazzini
> [01:42:37](https://www.youtube.com/watch?v=OW-atKrg0T4&t=6157s) Having to test new designs and test your assumptions of what your audience knows is pretty much eternal. — Chris Espinosa
## Mentioned 3DO, Adobe Photoshop, Annette Wagner, Apple, Apple Computer, Inc., Apple II, Apple IIe, Apple III, Apple Presents Apple, Apple Presents... Apple //e, AppleScript, Apple Writer, Barry Smith, Bill Atkinson, Bob Glass, Bob Harriet, Bruce Tognazzini, Byte magazine, Chris Dewar, Chris Espinosa, Computer History Museum, Daly City, California, Digital Equipment Corporation (DEC), Digital Research, Digital Research GEM, Don Wise, Electronic Arts, Ellen Nold, Fortune 32:16, Gail Pilkington, Gates Computer Science Building, George Michael, Greg Stikeleather, Hewlett-Packard, HP NewWave, HyperCard, IBM, J.D. Eisenberg, Jean-Louis Gassée, Jeannie Treichel, Jef Raskin, John Couch, Joy Mountford, Kate Gomoll, Ken Victor, Larry Breed, Larry Tesler, Lawrence Livermore National Laboratory, Laurie Vertelney, Lisa, Lisa Desktop Manager, LisaDraw, Lisa Filer, LisaGraph, LisaList, LisaWrite, MacDraw, Macintosh, Macintosh Toolbox, Mac OS 8, MacPaint, MacSketch, Mark Cutter, MicroPro, Microsoft, Microsoft Excel, Microsoft Office, Microsoft Windows, MIT Connection Machine CM-5, Moffett Field, Motorola 68000, NASA Ames Research Center, National Computer Conference (NCC), NeXT, Norm Hardy, Pat Marriott, Personal Software / VisiCorp, Peter Speer, PolyMorphic Systems Poly-88, Quark Catalyst, Qume, RAND JOHNNIAC, Renault, Rod Holt, Smalltalk, Smalltalk-80, Stanford University, Steve Jobs, Steve Smith, Steve Wozniak, Sue Espinosa, Sun Microsystems, Tektronix, Thinking Machines, Trip Hawkins, UCSD Pascal, VisiCalc, Visi On, Wallis Judd, Wang Laboratories, Wayne Rosing, Windows 95, WordStar, Xerox PARC, Xerox Smalltalk, Xerox Star (8010 Star Information System)
## Video description “Origins of the Apple Human Interface” is a lecture delivered by Larry Tesler and Chris Espinosa. Held at the Computer History Museum in Mountain View, California, on October 28, 1997.
Catalog number: 102706165
[Source](https://www.youtube.com/watch?v=OW-atKrg0T4)