Origins of the Apple Human Interface

Origins of the Apple Human Interface — Computer History Museum

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)

中文简报

苹果人机交互界面的起源 拉里·泰斯勒(Larry Tesler)与克里斯·埃斯皮诺萨(Chris Espinosa)借助档案文件,详细解析了苹果公司在1979年至1980年代中期如何确立其基础性的图形用户界面标准。泰斯勒详述了Lisa项目背后激烈的技术争论与快速可用性测试,正是这些测试催生了单键鼠标、屏幕顶部菜单栏、标准化键盘快捷键以及桌面图标隐喻。埃斯皮诺萨则追溯了Apple II团队并行的可用性研究工作,展示了零售教程与文档交付期限如何促成了后来被Macintosh所继承的规范化开发者指南。两人共同打破了苹果仅是抄袭施乐帕拓高(Xerox PARC)的传言,强调了针对完全初学者开展的严格实证测试如何从根本上重塑了个人计算。 拉里·泰斯勒与克里斯·埃斯皮诺萨回顾了苹果人机界面的诞生历程,依托1979至1980年的内部规范文件,证明了苹果是通过实证可用性测试而非直接模仿,从而在很大程度上背离了施乐帕拓高的模式。 (6:34) 苹果引入了针对毫无经验的受试者(包括苹果入职第一天的员工及外部非电脑用户)的快速用户测试,以解决围绕单键鼠标、屏幕顶部菜单栏以及剪切和粘贴范式展开的设计争论。 (35:19) Macintosh的用户界面规范融合了Lisa的图形鼠标机制与Apple II部门由文档驱动的一致性标准,克服了第三方开发者对基于ROM的统一界面的激烈抵制。 (87:08) 早期的办公套件策略假定用户只需要一个捆绑的核心套件,这一前提由于高昂的成本和封闭的软件生态导致Lisa在商业上受挫,直到数十年后才被微软Office证实其合理性。 (108:41)

Source quotes

[102:51] Chris Espinosa: 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. [78:14] Bruce Tognazzini: When a user hits a snag, he will assume it is his fault; he will not report it, he will hide it. [102:37] Chris Espinosa: Having to test new designs and test your assumptions of what your audience knows is pretty much eternal.

Original transcript

[0:00] [Music] [1:01] eventually opening a public museum [1:03] focused on the history of computers [1:06] hardware software documentation and so [1:08] forth designed for adults not a kid's [1:10] hands-on museum but it's an adults [1:12] oriented museum it's a long-term project [1:14] we're probably going to take four or [1:15] five years to get there to build a [1:16] building to find a location in sight and [1:18] so forth the meantime we're focusing on [1:21] continuing to build a collection which [1:22] is the finest in the world it's got [1:24] thousands of artifacts and thousands of [1:25] photographs and documents and books and [1:27] so forth we're inviting people to help [1:30] us with this project by doing lots of [1:32] things we have weekend volunteer days [1:35] when people come and help us work on the [1:36] collection we'd like as many people as [1:39] can to become members of the museum and [1:42] you can do that in several ways one [1:44] program if we just started is that you [1:47] can become a member for a hundred [1:49] dollars and get a card that gives you [1:50] access to the History Center and also [1:53] gets you access to Moffett Field so on [1:56] Wednesdays and Saturdays you can without [1:58] going through the process you went [1:59] through today get on to the field and to [2:01] have access to our visible search [2:03] location in addition for the next I [2:08] guess about six months you have an [2:09] opportunity one time only to become a [2:11] founding member of the Computer History [2:12] Center by donating a thousand dollars or [2:14] more and be permanently enshrined as one [2:16] of the founders of the Computer History [2:18] Center it's the same kind of program [2:19] that was done by the computer museum ten [2:22] or twelve years ago when it was in its [2:23] founding stages what else are we doing [2:28] we're we're having a we are mounting a [2:31] bunch of expeditions in various places [2:34] we've done several at trade shows and [2:36] conferences we've got one that's going [2:38] to be opening next week at the new gates [2:39] computer science building it's Stanford [2:41] where we're taking part of our [2:42] collection and and showing it off and [2:45] until we have our own permanent space [2:47] that's a good way to show off some of [2:49] our wares we've got more stuff coming as [2:52] we speak there are four tractors loaded [2:54] being loaded in Boston and heading [2:56] across the country with the next [2:58] installment of of the machines and and [3:02] the part of the artifacts from Boston [3:04] and [3:04] rooted in there is what the johniac and [3:08] cm5 thinking machine that we just got [3:11] from MIT and a whole bunch of other very [3:13] valuable artifacts if you want to get [3:16] more information about the Computer [3:20] History Center talk to me or Gwynn bell [3:21] or Zoe or dag or any of the other people [3:23] who are on staff we'd like to thank the [3:27] people at NASA Ames here for their [3:29] hospitality both in the use of this [3:31] conference center but also in the use of [3:33] the warehouse space for which we're very [3:35] much in debt to them there are some [3:38] flyers in the back of that you can pick [3:39] up that describe what's going on here of [3:42] both NASA and generally in their center [3:44] for excellence and information [3:45] technology this is one of a series of [3:48] talks that we've been giving in [3:50] cooperation with a Bay Area Computer [3:52] History perspectives P Turner Spee runs [3:54] that and he will introduce tonight's [3:56] speakers Thank You Lynn yeah I don't [4:00] really run Bay Area Computer History [4:02] perspectives it's more a joint venture [4:04] between myself I work at Sun [4:06] Microsystems and Jeannie trico also [4:08] works at Sun Microsystems and Jeannie [4:11] was at Xerox PARC [4:12] many years ago I was part of history [4:15] herself [4:17] we started this computer talk series [4:19] over four years ago like 1973 and two of [4:24] our speakers at the first program are [4:26] here in the front row [4:27] no Hardy and George Michael from [4:29] Livermore and so a lot of people have [4:31] been coming back over the years from one [4:33] program to another and Larry Tesler [4:36] who's one of our two speakers tonight [4:38] himself did a program along with bob [4:41] Harriet Larry breed Don wise over three [4:44] years ago on the Stanford card stunts [4:48] which I wrote up in the description was [4:51] the largest bitmap display ever you know [4:53] it was like several thousand students [4:56] holding up colored cards and sequencing [4:58] that was a feat itself to do the [5:00] programming of the instructions back [5:02] then at that time and Larry has also [5:06] been coming to many of the programs [5:08] before and since then so it's like this [5:11] history talk series has developed the [5:13] history of its own so tonight we have [5:17] and Chris Espinosa from Apple talking [5:21] about the early Apple user interfaces [5:24] and I think as you may have heard Larry [5:28] came to Apple from Xerox PARC back 1980 [5:32] and he so figured he was bringing a lot [5:34] of user interface knowledge with him [5:36] only he's found out recently that user [5:39] interface testing and development [5:41] existed at Apple before 1980 and Chris [5:44] had a part in that Chris I think that's [5:47] correct was probably the youngest Apple [5:49] employee ever did demos at Apple while a [5:53] high school student [5:54] so Larry yeah pass the mic where's Barry [5:59] there you are okay yeah I already have [6:04] one [6:10] it's your tape in there Chris okay fine [6:16] good in here [6:34] okay well glad to be here this is a talk [6:38] actually that's based on one that [6:40] Kristen I gave it Apple back in July and [6:42] we got clearance thankfully from the [6:45] Apple lawyers which came about two or [6:46] three weeks ago so we could give it here [6:49] just in time to announce it and we're [6:51] grateful to Apple to release this for [6:55] public disclosure because we think it's [6:57] a general interest asking about what was [7:02] early user interface design at Apple is [7:04] kind of like asking about early engine [7:05] design at mercedes-benz or something [7:08] everybody was doing it so paying on who [7:11] you you could have gotten a lot of [7:12] people up here to give a talk and you [7:14] get different perspectives on the same [7:16] things that happened so today you're [7:18] going to get the perspective of a couple [7:19] of us to get it to be a little more [7:21] grounded in something more closer to [7:23] fact than the opinion or perspective [7:26] we're trying to use as much as possible [7:28] actual original documents that that were [7:31] created at the time so you see actual [7:33] contemporaneous thinking as it was going [7:37] on instead of just our memories which [7:39] fade over time and and tend to [7:42] aggrandize over time and so on so here's [7:46] something which has which is not from [7:48] Apple this is the cover of bite from was [7:52] it August 81 that was the small talk [7:57] issue colorful this one doesn't have [7:59] color of us very colorful balloon and [8:02] the reason they show it is that there [8:05] was a lot of influence from Xerox [8:06] obviously on the user interfaces that [8:10] were done on the Lisa and the Macintosh [8:11] but maybe not as much as some people [8:14] think media tends to just say oh they [8:16] just copied it so I'm gonna show you [8:20] what it looked like to be working on [8:23] from that article which I wrote to be [8:27] working on a small talk at that time [8:30] 1981 and you see what the windows look [8:33] like kind of a little rectangular title [8:36] scrollbar without any arrows and and [8:40] it'll pop up menu there are two pop-up [8:42] menus that you could use for each window [8:45] so it was a pretty different looking in [8:47] her face and one of the principles [8:56] though that was in the small talk [8:57] environment was to have no modes and [9:00] there was actually yeah a photograph of [9:03] a t-shirt that was made for me by a [9:05] friend that said don't load me in that [9:09] represented service this mission I was [9:11] on to try to eliminate all modes from [9:13] user interfaces which is necessarily a [9:15] good idea but it was definitely the [9:17] mission I was on and at the end of that [9:22] article had mentioned that Apple [9:23] Computer had gotten a license to small [9:25] talk and was maybe going to do something [9:27] with it but maybe not gonna do anything [9:29] with it and in fact Apple and Europe [9:33] Eckerd Digital Equipment & Tektronix all [9:36] did do various amounts of small talk [9:38] development after that but it was really [9:40] independent companies that that managed [9:43] to make small talk somewhat of a success [9:46] I'm jumping to the end here before I go [9:48] to the beginning just to let people know [9:50] what the Lisa was the idea of the Lisa [9:53] was to have something that was very very [9:55] easy to use people working people loved [9:57] the Apple 2 which was what we had at the [9:58] time at Apple but it took a long time to [10:00] learn how to use it and what we wanted [10:03] to end up with was something that was [10:04] easy to learn and just to show you that [10:06] we did do that this is a study done at [10:08] the end where there were 18 subjects 6 [10:10] using Lisa graph 6 using Lisa right Lisa [10:12] list [10:13] Lisa graph was a business graphics [10:15] program at least list was a list manager [10:16] kind of flat file database [10:18] Lisa Wright was a word processor and as [10:20] you see for all but one user using Lisa [10:23] list it was under 20 minutes to get [10:26] through the core competency to use the [10:29] application and if you ever had a chance [10:31] to use a Lisa and I hope hope to be [10:33] one-upper reading here some day then [10:35] you'll see that it was extremely easy in [10:38] many ways more bulletproof I'd say than [10:41] the Mac that's simpler than the Mac [10:43] actually but but we loaded a lot of [10:46] things into it to try to make it so [10:48] people couldn't get themselves in [10:50] trouble ok so let's start at the [10:52] beginning I started at Apple on July 17 [10:55] 1980 and I just left there a few months [10:58] I was there for 17 years and this memo [11:01] was written on July 18 1980 so one thing [11:03] I discovered when I left big Xerox [11:05] Corporation and went to this little [11:07] Apple start-up was that you just really [11:09] get engaged immediately and they put you [11:11] right to work and one thing I was told [11:14] the day I got there was that the user [11:17] interface design was basically done and [11:20] we were they were just going to you know [11:23] write it up and finalize it and [11:25] implement it and that was the end of it [11:26] and it was too bad I took so long to [11:29] show up at the office because they were [11:31] hoping I could have contributed to it [11:32] but now there was no time left to do [11:33] that and this was the 18th and they told [11:37] me that all the decisions had to be made [11:38] by the 23rd and by one week later the [11:41] external research external reference [11:42] specification had to be done which was [11:44] the complete spec but we couldn't [11:46] compromise quality at all and and so [11:49] what could I do between the 18th and the [11:51] 23rd to make sure we made all the right [11:52] decisions so I started explaining how it [11:55] was really necessary to do months of [11:56] user testing and careful iteration and I [12:00] gave my whole spiel about the right way [12:01] to design software and they said well [12:04] sorry we only have 5 days into the [12:06] weekend in there so we got together and [12:11] we can't with a compromise which was to [12:13] lay out a schedule that was very [12:14] aggressive and people promised that they [12:15] would meet their part so let's go [12:17] through the schedule this was the 18th [12:24] turn this a little easier to get out [12:35] this No [12:37] it is pull oh that kind of pointed [12:44] you're the one with the laser oh okay [12:51] so here with the schedule Monday we're [12:56] going to run user tests so we're gonna [13:00] well we're all gonna try it ourselves [13:02] everybody's going to try bill atkinson's [13:03] prototype Bill Atkinson was the person [13:05] building the prototypes at that time and [13:06] thinking up a lot of the ideas and we're [13:09] going to evaluate several issues that [13:11] were going on then we're going to bring [13:13] in after two hours of that we're gonna [13:15] take a break for lunch then at 1 o'clock [13:17] we were going to bring in sue Espinosa [13:19] who was in charge of training and also [13:20] coincidentally is Chris husband knows [13:22] his mother and then she was going to [13:25] give her opinions about that and maybe [13:28] help us decide on what would be easiest [13:31] to train in her opinion and then at 2 [13:33] o'clock we were gonna discuss for an [13:35] hour and all of more issues and now we [13:39] would be done we will have discussed all [13:41] the issues and then between 3 and 5 [13:43] o'clock we would present the solvus [13:44] Steve Jobs and Steve would make the [13:46] decision which which we knew would be [13:48] definitely forthcoming and then on [13:53] Tuesday we were going to take the things [13:57] that Steve liked and we were going to [13:58] test them on subjects from 9 to 10 two [14:02] subjects two more subjects from 10 to 12 [14:05] we must've figured we'd be slowing down [14:06] by then 1 2 3 we evaluate the test [14:09] results [14:12] so that was it okay so remember that was [14:15] supposed to be July 22nd okay so now the [14:19] rest of the for the next 15 minutes or [14:22] so keep in mind that that was the [14:23] scheduled for July 21st and 22nd okay [14:26] well we actually did that we did all [14:29] those tests we did talk to Steve Jobs he [14:32] gave his opinions we did some more [14:33] testing and then bill went to write up a [14:37] user interface specification external [14:39] reference specification I was a little [14:42] worried because we hadn't really done [14:44] extensive testing but we tested a couple [14:46] things so this is data August 6 which [14:49] was as you know as you may notice a few [14:52] days later than the deadline date that [14:53] we had provided but it took a while and [14:55] it said that you had one week to review [14:59] and return your comments so we were [15:01] already starting to slow down a little [15:02] bit here and let's look at some of the [15:07] names of the people who got this memo [15:08] because it'll turn up to be important [15:11] later in the story or just interesting [15:12] right now Ken Victor who is gonna [15:15] respond to it later and jef raskin also [15:18] barry smith in addition to that notice [15:21] we sent it to Mike Markkula who was one [15:23] of the founders of the company and Steve [15:24] Jobs trip Hawkins who was the head of [15:26] product marketing we sent it to [15:28] everybody in Lisa software group we only [15:30] send one copy to Lisa Hardware they get [15:32] to share we send it to every vice [15:36] president we could think of and to our [15:39] two people who became Apple fellow [15:40] somewhat later rod Holt and Steve [15:42] Wozniak who's here in the back today I [15:45] don't know if he remembers receiving [15:47] this memo [15:49] but he probably does it was pretty [15:51] dramatic okay so we did some I think we [15:55] did some things right they´ll started [15:56] out by talking about who is the customer [15:59] so it wasn't just some easy-to-use [16:01] computer it was an easy to use computer [16:02] for specific people so what was it first [16:05] of all it's a single user workstation [16:07] that was an important point in those [16:08] days was still an important point if you [16:10] were its son or something [16:11] and designed to enrich the productivity [16:14] of the office worker so our market was [16:16] office workers and it went on and talked [16:18] about the hardware and so on it's more [16:21] than a piece of hardware though it [16:22] includes major software and we had [16:24] specific applications in mind word [16:26] processing graphics data management and [16:28] communications it wasn't intended to run [16:30] thousands of applications not the Lisa [16:32] the concept that trip Hawkins had was [16:35] they had done studies and they found [16:37] that most people on the Apple too ended [16:38] up using only two or three applications [16:40] therefore this was the great leap all we [16:44] need to do is provide two or three [16:44] applications that's all anybody will [16:46] ever want it was an interesting theory [16:48] and Apple funded a whole project based [16:52] on that assumption and then it said the [16:55] purse upwards integrated through a [16:57] powerful and simple user interface and [16:59] it doesn't say it here but John couch [17:00] who was in charge of the Lisa project [17:02] and did a sort of Kennedy we were gonna [17:05] send a man to the moon and bring him [17:06] back thing he said all I want is I want [17:09] to be able to go into a spreadsheet make [17:11] some put some numbers in go and graph [17:14] them take the graph paste it into my [17:16] word processor document and included in [17:18] a report you didn't say paste you know [17:20] put it in my word processor document he [17:22] said oh I can do all those things an [17:23] integrated way then will be way ahead of [17:25] anything available on the Apple to where [17:27] there are all these separate programs [17:28] that don't interact in our interact with [17:30] each other that's all he wanted whenever [17:32] we brought him any issue he said [17:33] remember what I want and he went through [17:34] the whole mantra and that was a very [17:36] healthy thing it kept us focused and [17:39] then we also knew when we were done [17:42] well who are the users non-technical non [17:45] analytical people none analytical it's [17:47] very important point first time users [17:51] well 1980 there were a lot of first-time [17:54] users almost everybody and here are [17:57] examples administrative assistants and [17:59] secretaries also secondarily managers [18:02] accountants and executives wasn't for [18:04] programmers wasn't for kids it wasn't [18:06] for people at home doing recipes this [18:08] was an office system and so when you [18:11] start looking at it and comparing it [18:13] maybe with the math you'll see some [18:14] differences based on that and you may [18:16] see some similarities to Windows design [18:20] philosophy so there was a whole section [18:22] on the design philosophy and what were [18:23] the most important features to put in [18:25] graphic images well I was pretty vague [18:28] menus a pointing device that you could [18:32] move around freely as opposed to the [18:35] cursor keys we were using up to then and [18:37] we were going to let you invoke commands [18:39] from the keyboard also because there [18:40] were times when you would do things over [18:42] and over and people felt that sometimes [18:44] the mouse slowed you down a bit so let's [18:47] look at this keyboard this was the [18:50] keyboard that existed on the hardware [18:52] when I arrived it had a code key in the [18:56] upper left corner and some of the keys [18:59] on their fronts had some characters in [19:02] other words in order to make the [19:04] keyboard the width they wanted they [19:05] couldn't fit all the characters on the [19:06] keys so they squeezed a few extra [19:09] characters on the Front's of the keys [19:10] and then have a special key to invoke [19:11] those and later we decided we could use [19:14] that key together with other keys to do [19:16] another function that you'll see later [19:18] now I didn't like the hardware designed [19:21] too much and I wanted to change it but [19:22] they said you can't change that you know [19:23] you came from a research place we just [19:25] have to ship the hardware that we [19:26] already built otherwise we won't be able [19:28] to ship this product when it's gonna go [19:29] to market I said well when is that and [19:30] they said six months that was a 1982 [19:35] jump ahead and ship till middle of 83 [19:37] probably my fault okay [19:40] so here was the pointing device kind of [19:43] a brick that's a mouse and you know I [19:47] the color is me I added color last night [19:49] just to highlight things you should look [19:50] at but it had two buttons at that time [19:52] and I hand wrote on here something about [19:54] the shape I wasn't too happy with the [19:55] shape and I wasn't sure what [19:57] distinguished these two keys and whether [19:59] there was a little space between them [20:00] where they were flush or what so you'll [20:03] see some of my handwritten scribbles on [20:04] these memos and here's how the mouse was [20:07] used well actually they didn't know a [20:08] lot of how the mouse was used yet they [20:09] mostly were focused on the window [20:11] manager how the user would manage the [20:13] windows on what we now call the desktop [20:15] and so at that time the idea was this [20:18] there would be a click and a drag and [20:22] those are two things you could do you [20:24] could click and let go or you could [20:25] click hold drag the mouse and let go [20:27] and sometimes we called it drag [20:30] sometimes we called it draw various [20:31] nicknames and then there was the buttons [20:33] got names the point button and the grow [20:36] button and depending on where you [20:37] pointed in whether you clicked or [20:38] dragged and which but you know which [20:40] button you used this page here shows [20:43] what happens if you went into the title [20:45] tab of a window that little thing that [20:46] had the name and it either would display [20:48] the window menu move the window open or [20:51] close the window or change the size of [20:53] the window all of it done by clicking in [20:55] the title so there was no grow box in [20:57] the lower right there were no menus that [20:59] were it was all done with just one of [21:01] two mouse buttons and a click or drag [21:03] operation now there was a menu at the [21:06] bottom of the window but had nothing to [21:07] do with window operations it had to do [21:08] with operating on the content inside the [21:10] window we'll get to that now I should [21:13] stop saying when I got there because by [21:15] then I'd already been here for two weeks [21:16] so I had some influence on this I can't [21:21] remember what so here's a later two Jeff [21:23] now Jeff isn't misspelled that's jef [21:25] raskin who would does spell his name [21:26] that way and he was for some reason [21:28] became the person who we were always [21:30] sending letters to on the lisa project [21:31] and as you see this scrollbar was on the [21:34] left side it had the horizontal [21:36] scrolling arrows at the top the vertical [21:38] scrolling hours at the bottom now those [21:41] of you who know the the next machine [21:42] know that that's the features that you [21:44] have the two arrows close to each other [21:46] so you don't have to move very far to go [21:48] between the two arrows that was actually [21:50] designed in 1980 by Bill and then at the [21:53] bottom in the Edit menu had [21:54] cut paste doop to copy things and undo [21:57] and then on the side there were the [22:00] equivalent of today's icons this was [22:03] taken from small talk where you took the [22:04] tab of a window threw away the window [22:06] and just kept the tab called it [22:08] collapsing the window and these were [22:09] windows that were available but closed [22:11] right now and you could open them up [22:18] okay then we had this idea of billion [22:21] menus there what just to jump ahead [22:23] they're what we call dialog boxes today [22:25] and there were two kinds there were [22:27] kinds where you somehow open a submenu [22:33] and you get to type into that submenu [22:35] don't ask me exactly how and the other [22:37] was where it actually opens up a big box [22:39] like we know today that was this thing [22:41] called forms and so it was a kind of a [22:44] vague notion at that time no one had [22:45] actually drawn any pictures even of what [22:47] those looked like I think and again we [22:49] said that menu commands can be a vote [22:50] from the keyboard and I put a little [22:51] note saying disagree somewhat and I wish [22:54] I could remember what I disagreed with I [22:57] think I was afraid they would do too [22:59] much keyboard stuff they were scroll [23:03] bars and you would hold a button down to [23:06] scroll continuously now there was an [23:08] interesting idea here that you could [23:09] double click to flip to the next page [23:10] you know anybody that knows about user [23:13] interface design with with single and [23:15] double clicks usually you make it so [23:17] that when you click once you can start [23:19] doing something and then when the second [23:21] click comes it doesn't sort of negate [23:23] what you already started to do this is [23:25] kind of interesting because you clicked [23:26] once it would sort of start to scroll a [23:27] little and when you click the second [23:28] time we would realize you wanted to jump [23:30] a lot so you'd get a little motion and [23:32] then a jump should I actually might have [23:34] been kind of cute but I don't think we [23:35] ever implemented it then there was [23:38] something in the called the elevator [23:40] shaft with the elevator in it and that [23:42] was what is still today that little box [23:45] on the scroll bar that you see there was [23:49] a abbreviations window that was that [23:50] code key we had to find a use for it so [23:52] you could type code and then hit a [23:54] letter on the keyboard it would look up [23:56] in a table and an expand your [23:57] abbreviation this was kind of taking the [23:58] kind of thing you'd find on a weighing [23:59] word processors so we put that in [24:01] because this was for secretaries [24:05] and there was something called the [24:07] system error window and that's what you [24:10] now know as alert boxes [24:11] in Mac and Windows and these were things [24:13] that would come up when there was a [24:14] problem and it would make some kind of [24:16] beef and it would tell you what the [24:18] problem was so I put a little question [24:20] mark here is the system frozen when that [24:22] comes up can you do other things and we [24:25] eventually decided it was modal but [24:27] actually that's a quite a while to [24:28] decide now we talked about testing we [24:33] said that the designs already based on [24:35] studies of user reactions to various [24:36] models as you saw we did three or four [24:38] hours of testing and we're gonna do more [24:42] testing and avoid any glaring design [24:45] flaws I was happy that that was put in [24:49] because that meant we could go and fix [24:50] some more problems than I was sure was [24:52] there because we hadn't done enough [24:53] testing yet so why did it come down to [24:55] this what it looked like the basic model [24:57] was overlapping windows which is right [24:59] from small talk [24:59] there was that box at the top just like [25:02] in Smalltalk that little title bar the [25:04] scroll bar was on the left just like in [25:05] small talk only instead of just that [25:07] little box they were the scroll the [25:09] scroll arrows there we thought it would [25:10] be nice to have something to point to [25:11] and small talk you push the button and [25:13] then the arrows appeared and we thought [25:15] that was a little weird and there was [25:17] this menu at the bottom and now if any [25:19] of you who's ever used a system called [25:20] UCSD Pascal if you remember they were [25:25] menus in UCSD Pascal and you would type [25:27] the first letter of the menu name and it [25:29] would bring up a submenu and you typed [25:31] the first letter of menu name and you go [25:32] through a hierarchy of menus now also [25:35] there was a machine Who am I gonna [25:36] forget the pig gonna forget the number [25:38] heel at Packard computer mm now it was a [25:44] later model in that HP something [25:45] thousand that had a rope the row of [25:48] function keys on the top of the keyboard [25:49] and at the bottom of the screen under [25:52] each key still have it they were in use [25:57] you hit that key that would activate [25:58] that menu item these were the two [26:00] products that that the authors of this [26:02] interface knew the best they used UCSD [26:04] Pascal dealer software development half [26:06] of them came for you love Packard and so [26:08] this was kind of a blend and so you [26:10] could they had function keys at the top [26:12] of the keyboard that you could hit that [26:13] would make invoke the corresponding [26:15] things and they also had these [26:17] hierarchal menus that were straight out [26:18] of UCSD Pascal not the little pop-ups [26:23] that were in small talk so that's where [26:25] it was in August cut and paste were two [26:29] of the commands in the menu that came [26:31] from small talk and as you see there was [26:33] a wastebasket that's what you called the [26:34] clipboard today we used to call the [26:36] wastebasket different from the trash can [26:38] which was a confusion we had later and [26:40] that's why we changed the name but when [26:42] you cut something and when the [26:43] wastebasket like in the office you cut [26:44] something and throw in the wastebasket [26:45] but then you could take it and paste it [26:47] somewhere else and it was serve a weak [26:49] metaphor but and so you'd select it with [26:51] the mouse notice that when you select it [26:53] there's this little arrow here that [26:55] turns out to be a significant point [26:56] later I'm moving fast because there are [26:59] a lot of slides here now Ken Viktor [27:02] remember was Ken here today yeah Ken was [27:05] one of the reviewers of the document and [27:06] he provided some input very very quickly [27:09] and he said why can you only select it [27:14] with the mouse [27:15] now this he must be someone who used [27:16] Emacs or something he wanted you to be [27:18] able to select from the keyboard [27:20] you know fourth line third word seventh [27:23] character you know she'd be able to [27:24] specify what you want and fourth [27:27] occurrence of the word Lisa you should [27:29] be able to say things like that and he [27:31] was maybe years either you know he sort [27:34] of didn't get it or he was years ahead [27:35] of his time whichever way you want to [27:38] look at it but it kind of this is what [27:41] he would like to use and we had to sort [27:43] of explain to him that our target market [27:45] didn't want to find the fourth [27:46] occurrence of Lisa in the third [27:47] paragraph they could see it with their [27:49] own eyes and select it with the mouse [27:50] and that was just fine now here was [27:53] something I wish we'd listened to at [27:55] this point it said that you were growing [27:59] windows from the lower right now I [28:01] showed you something before showing it [28:02] you grow it at the grew at the top I [28:04] think in this document it was sort of [28:05] ambiguous whether you grew it from the [28:06] top or the lower right and he didn't [28:09] like that idea he wanted to be able to [28:11] grow from any side and I do think that's [28:15] better and we didn't pay any attention [28:17] to him I think we were worried about the [28:19] screen space being too tight or [28:20] something moving a document within a [28:23] window he wanted to know whether we [28:25] could do what we now call live scrolling [28:27] as you move that elevator up and down [28:28] the shaft [28:29] the text to move continuously problem [28:32] was that the Lisa processor ran at what [28:35] 1/4 5 megahertz it didn't even seem that [28:39] fast to me I couldn't do it so some [28:44] things were just pragmatic he didn't [28:48] like the idea of cut and paste he wanted [28:49] us to use move copy and delete and [28:51] transpose excuse me just getting over a [28:56] cold in other words that you have two [28:58] things you would select move this to [29:00] there copy this to there transpose these [29:02] two things well this wasn't the first [29:04] time I heard that argument and in fact [29:06] this one of those religious arguments [29:08] like one button or one versus two [29:09] buttons do you want cut copy paste you [29:11] want you want move copy delete the [29:15] reason we went for well you can argue [29:17] either one it is two steps to do cut and [29:20] paste but there are a lot of advantages [29:21] to it one is that you know moving [29:24] deletes or start with the same thing [29:26] some people think that's good some bad [29:28] another reason is that you don't have to [29:31] be able to see the destination when you [29:33] are copying or cutting the source that's [29:35] the most important thing and on the [29:37] screen of limited size when you have [29:38] windows overlapping it's sometimes very [29:40] hard to get things all lined up so you [29:41] can specify two targets or you have [29:43] windows popping up and down you get very [29:45] confused the other thing is that I had a [29:48] secret agenda which is I thought that [29:49] the machine should be used not for what [29:51] they talked about office systems I [29:53] thought well that was good but I don't [29:54] want to be used just for that I thought [29:56] it was it would be a great machine for [29:58] publishing and that would be able to do [29:59] cut and paste into page layout which was [30:01] my own personal interest and so I was [30:04] advocating that because that was [30:05] definitely the way you'd want to do [30:06] paste page makeup but we did user [30:09] testing and the users slightly prefer to [30:12] cut and paste mam the wastebasket window [30:15] was able to not only have one thing you [30:17] cut out but multiple things you cut out [30:19] and he had some comments about how they [30:21] deal with the multiple items some of us [30:24] thought it should only hold one he [30:26] thought it was okay to have multiple [30:27] ones he lost in the end okay here's some [30:31] comments for me I was complaining [30:33] because nowhere in the spec did it say [30:35] what the response time should be it said [30:37] all about the user what they do with it [30:38] but it never said that this needs to [30:40] respond within half a second this knee [30:42] to respond within two seconds that needs [30:44] to respond within 10 seconds never said [30:46] it anywhere and I was worried if it [30:47] didn't say it [30:48] the engineers wouldn't do it if any of [30:50] you ever used to Lisa well it was really [30:54] slow I lost that argument they said [30:57] it'll be as fast as we can make it and [30:59] that was too slow then they'd have [31:03] talked about a really interesting [31:05] question which was well we want [31:06] hierarchical menus and we want keyboard [31:09] accessible commands so we seem to be [31:10] fixated on the way they do it and UCSD [31:12] Pascal you type a key get another menu [31:14] type of key get another menu and that [31:16] just bothered me and I thought there's a [31:19] lot of mistakes could be made people are [31:20] gonna forget which level of the [31:21] hierarchy they're in how they get back [31:23] out of it again it's just gonna be too [31:24] complicated and I didn't like it [31:27] so the will come to how that was solved [31:31] later the other thing I was complaining [31:33] about was the two button mouse we didn't [31:35] use the second button for much else for [31:37] a lot of different things we didn't use [31:39] it for much and when we did there was no [31:41] way to remember which button did what [31:43] and so I just wanted to eject the second [31:45] button and just have one and that's [31:48] August 13th operations on Windows I [31:54] proposed here that that we have this box [31:58] in the lower right hand corner that we [32:00] use for growing the window instead of [32:01] doing it from the top and also I thought [32:04] there would be ought to be a way to [32:05] split a window into panes and then I had [32:12] a whole section here about moving a [32:14] document within a window I go and talk [32:15] about scrolling and why I don't like the [32:18] way it is and then I said why don't we [32:20] put you know one arrow at the top of the [32:22] scroll bar one at the bottom of the [32:23] scroll bar and I actually prototyped it [32:29] those are you know that who know the [32:31] Xerox star know that the Xerox star had [32:34] that feature those of us who were from [32:37] Xerox were under a confidentiality [32:38] agreement that we weren't allowed to [32:39] tell the other Apple people about the [32:42] star and so as you go through this [32:45] you'll sometimes find that things seem [32:48] like isn't it an obvious solution you [32:49] could have got it from the star but none [32:51] of us are able to say why this how the [32:52] star was we were only live to comment on [32:55] other people's proposals and make new [32:57] ones and it was an interesting kind of [33:00] dynamic but gradually over times abuse a [33:03] few star like things crept in but not [33:05] many until the star actually shipped or [33:07] was announced in June of 81 but here we [33:10] are in 1980 and I suggested we try and I [33:13] shaped cursor for text selection instead [33:16] of an arrow and actually is something I [33:18] had done in my early years at Xerox in a [33:20] particular word processor I'd done I [33:22] also said I wish the cursor would be [33:23] bigger than 16 by 16 to go to 32 by 32 [33:27] which which we eventually did menus this [33:32] was what August 18th I think we should [33:36] experiment with menus at the top or [33:37] right of the window or even totally [33:39] detached at the top of the screen full [33:41] width so up to this time we were doing [33:43] sort of the way Windows does and every [33:45] window had its own menu and I was [33:48] thinking you know maybe we got to put it [33:50] at the top and you'll see why in a [33:51] minute when you see the pictures and [33:53] then I said hierarchical menus well [33:55] maybe we have to have and we can't get [33:57] rid of them but could we make a mouse [33:58] access instead of having to type all [34:00] these keystrokes so these were my two [34:03] causes of the moment Barry Smith who was [34:06] in product marketing responded about the [34:08] same time and he said [34:16] at this point bill had moved the menu [34:19] bar that edit cut copy pasting from the [34:21] bottom of the window to the top of the [34:23] window that was the change and Barry [34:26] liked that he likes him a lot better [34:27] near the top call him near the top and [34:29] then he wanted to know though what would [34:31] happen if there were a lot of menu items [34:33] and could you could the menu scroll and [34:36] those of you know the history of the Mac [34:37] user interface know that at some point I [34:40] don't know 1990 or so or we start adding [34:42] scrolling to Mac menus but we didn't [34:45] have them in the early Macker and the [34:46] Lisa and I was against it because that [34:49] would have encouraged people to have a [34:50] lot of menu items and I didn't think [34:52] they should so I kept that from [34:53] happening [34:55] you can't constrain people though he [35:00] also did not like the fact that you had [35:01] to type multiple keystrokes through a [35:03] hierarchical menu and so he was thinking [35:06] maybe we could get to something where it [35:07] was a single keystroke to invoke a [35:08] command no matter where it was in the [35:10] hierarchy and I think Bill was was [35:12] experimenting with that at that time and [35:14] he also didn't like the two button mouse [35:15] he thought it was confusing so August [35:19] 18th I guess that was August 13th before [35:21] us a few days later after intense [35:25] political polite discussions heated [35:29] sometimes bill and I decided hey let's [35:32] get rid of the second button the shake [35:33] things up one button Mouse so we wrote [35:35] this memo together so that people knew [35:38] we were realest realest erious wrote [35:41] Santa to the usual suspects and we say [35:45] we recommend a change to a one-button [35:46] Mouse and whoever wrote this comment and [35:49] I glad I don't know who was said well [35:51] maybe not sure that's a good idea but [35:57] turned out trip Hawkins who later went [35:59] on to found Electronic Arts in 3do was [36:01] the product marketing manager he loved [36:03] it he said that's what we got to do we [36:05] got to think more and a [36:06] consumer-oriented really simple get rid [36:09] of all this you know computer science [36:12] concepts and give give people something [36:14] real simple he liked the one button so [36:16] after that we had a period sort of [36:18] goodwill where we were able to to do [36:21] user interface design without a lot of [36:22] complaining which ended after a while as [36:24] you'll see [36:26] well if you only have one button some [36:29] things are hard to do you can drag a [36:31] short selection but what if you want to [36:32] select something three pages long it's a [36:35] long time to drag from one end to the [36:36] other so we thought okay well we'll use [36:40] a shift key on the keyboard since this [36:42] doesn't happen very often you'll click [36:44] the beginning of the selection you'll [36:45] scroll to where you want to go hold down [36:46] the shift key and click the end of the [36:47] selection so that's where we got this [36:49] shift button thing adjusting selection [36:51] and then we said the one button Mouse is [36:54] superior look at the reasons it's [36:56] appearing human factors you don't have [36:58] to think of a name for each button [37:00] that's important when you're trying to [37:02] ship product in six months the mouse [37:04] will be cheaper to make because one less [37:06] button I mean just think of what the [37:07] cost of that little a little switches [37:11] it'll be and something a little more [37:14] profound someday when we start having [37:17] other things in mice on our computers [37:18] like joysticks for games tablets [37:21] touchscreens we'll be glad we only had [37:24] one button because that that one finger [37:26] or whatever or pen that the user using [37:28] is the button and that turned out to be [37:31] sort of prophetic although very few such [37:35] pointing devices take advantage of that [37:37] in fact they usually have buttons anyway [37:41] okay so August 22nd there's a revised [37:43] version of the user interface and it [37:46] says this is it now we're done so now [37:49] instead of a week you only have three [37:50] days to return comments because we must [37:52] be done there couldn't be more than one [37:54] or two comments they're probably just [37:55] typos or something at this point we were [37:58] working on this interface for a month [38:00] already [38:03] okay so what did it happen this version [38:07] had a concept called dim highlighting [38:09] this was introduced for the first time [38:11] that I know of here that if some of the [38:15] menu items instead of eliminating menu [38:17] items that weren't relevant which we [38:19] would dim them we would we've grade them [38:22] out instead of being black type they'd [38:23] be kind of in gray type and then we said [38:26] they can be invoked anyway if the user [38:27] wishes although they wouldn't do [38:29] anything and and we also were going to [38:32] use dim highlighting for another purpose [38:33] which was to show toggles and as you [38:35] know that was later changed to have [38:37] check marks instead of just using this [38:39] for two purposes because that was very [38:40] confusing but at that point we thought [38:43] we'd get away with one mechanism for [38:44] both things and it was Occam's razor one [38:46] mechanism will do they don't have to [38:48] well turned out that one didn't do so we [38:51] had to apologize to Ockham now as you [38:56] know you can do command keys on the Mac [38:58] or at least a keyboard and you can [38:59] invoke commands from the keyboard and we [39:01] knew it was important to reserve some [39:03] for the most common commands because [39:04] might be okay for an application to use [39:07] you know command shift J for something [39:10] but we wanted to be sure cut copy paste [39:12] undo were the same for everybody [39:13] bold italic underline and normal we [39:16] thought these would be used the most and [39:17] so they're all sequence I'm not going to [39:19] go through them all today but we had [39:20] various theories as you see here it's [39:22] rather different from what we ended up [39:23] with ZX CV was sort of the order on the [39:27] keyboard cut paste copy undo was the [39:28] order in the menu so that was it over [39:30] time we refined this list led to many [39:33] very heated arguments people would [39:36] rather argue about trivial things like [39:37] this than important things but we did [39:39] have fun arguing does anybody remember [39:43] what they really are today [39:47] that's right controlling trilby and then [39:50] for a cut X word stock oh I didn't know [39:57] that well we did X because it was a [40:04] cross out and we did V because it [40:06] pointed down like this and you were [40:07] inserting like an upside down carrot [40:08] that was paste and Z was the closest one [40:13] because we figured you'd undo a lot and [40:15] C for copy that was easy so that's how [40:18] we did that okay so this was the anatomy [40:21] of a window we had title tab now notice [40:23] next to the title tab we now moved the [40:26] menu to the top as was commented upon [40:28] someone obviously had got a sneak [40:30] preview draft and then earlier memo and [40:32] look there are menus that are popping [40:34] down from the menu bar first time when [40:37] it was the bottom that didn't make a [40:38] whole lot of sense but now that it was [40:39] the top bill kid instead of having the [40:41] menu come here and replace the previous [40:43] menu like it did in UCSD Pascal he could [40:46] use the second dimension and have a menu [40:48] pop out to the bottom don't ask us how [40:50] we were gonna do third level menus but [40:52] at this point this was good enough we [40:53] had two levels of menus and we were [40:55] happy over here there was the elevator [40:58] shaft now we called it the thumb instead [40:59] of the elevator because we wanted to [41:01] have horizontal scrolling too and [41:02] elevators in those days didn't go [41:03] horizontally although Scientific [41:05] American says they're about two and then [41:07] we had continuous scrolling arrows and [41:10] noticed the arrows point this way but [41:12] when you clicked on these arrows [41:14] the text was going to move that way as [41:17] opposed to the other way which is what [41:18] it does now and that was an interesting [41:21] argument that I think I have covered [41:22] here too okay we had active folders so [41:27] we had to have passive folders the [41:28] folder that wasn't active was passive [41:30] now look at the bottom who has never [41:32] seen Mac OS 8 and when you drag a window [41:36] to the bottom of the screen it just kind [41:38] of pops and becomes just a tab and then [41:40] you can click it and it'll end this [41:41] it'll slide open guess what that wasn't [41:43] the original design in August 1980 that [41:47] what we were going to do on the Lisa and [41:48] it only took 17 years to implement [41:54] Microsoft did something sort of similar [41:56] we're not really the same in between [41:58] there's some there are some differences [42:00] but I won't comment right now now so [42:03] what happened if the window was narrow [42:04] well if the neighborhood's window was [42:06] narrow this shows that the menu wouldn't [42:08] fit it would stick out and if it was [42:11] over in the right and it couldn't stick [42:12] out through the right he would stick out [42:13] to the left and it was too close to the [42:16] bottom of the screen then it would do [42:17] this and so bill showed all the cases [42:20] and I you know a lot of us weren't too [42:23] happy with this so I went back to Bill [42:25] again I said bill the top of the screen [42:27] the top of the screen none of us liked [42:31] the idea of a 2-lane menu which is the [42:32] way Microsoft solved it some version of [42:35] Windows and here's an example of a menu [42:38] item being selected notice he's now got [42:39] highlighting of the menu title and he's [42:40] got highlighting of the menu item bill [42:42] had a long night one night and came back [42:44] with that and we had the help menu in [42:46] here the way we operated was that bill [42:51] spend every night programming and the [42:52] next day we would do testing and arguing [42:53] I don't know when he slept actually did [42:56] he sleep and then he would do it again [42:58] every night now here's a memo from Gail [43:01] Pilkington and publications the people [43:03] writing manuals for the Lisa were key in [43:05] commenting on the user interface design [43:07] had a lot of suggestions and a lot of [43:09] good criticisms and Gail actually had [43:12] been a Xerox before so she said I don't [43:18] like pull down menus I think they're [43:20] ugly and they cover things up so you [43:23] know I'm trying to cut something and the [43:24] first thing it happens as menu come down [43:26] it covers up the thing I'm trying to cut [43:27] no good and then bill had this feature [43:30] that you could push she still has you [43:32] could drag the mouse along the menu bar [43:35] and the menus would pop up one at a time [43:37] and we thought this is great the user [43:39] can see all the available commands in [43:41] one swoop well she thought it was [43:43] terrible that you that you had to do [43:45] that to see all the commands I didn't [43:47] understand because in UCSD Pascal you [43:49] had a you know hit keys for ten minutes [43:51] to see all the commands so I didn't [43:53] quite get that she also didn't like the [43:56] idea of dim highlighting she thought we [43:58] should just suppress the items [43:59] altogether so we had dissent in the [44:01] group [44:02] and we always have to sit in the group I [44:04] just chose that because there's a memo [44:06] that I had an illustrative of dozens of [44:09] people who had to send over every issue [44:10] nothing specific about Gail [44:12] in particular she said you know last [44:14] version of the spec I thought we only [44:16] had one issue which was when the menu [44:18] when that little menu bar at the bottom [44:20] was full we didn't know what to do about [44:23] it [44:23] and you should have just solved that [44:26] instead of moving it to another place [44:28] adding dropdowns and all these other [44:29] things you over designed to solve the [44:32] problem and besides they don't like X [44:34] you know Z for cut next for a paste she [44:37] had her own proposal that was Nimonic [44:41] September 22nd was now a month after I [44:44] first said bill why try to top at the [44:47] screen they all had a very long night [44:48] and came back with a menu at the top of [44:51] the screen with command keys check marks [44:57] every day and he had everything in one [44:59] night he invented the entire mechanism [45:01] of the menu bar topped the screen to me [45:03] it was just a place to put what he [45:04] already had but he once he realized it [45:06] was there he could do a lot of other [45:07] things and he implemented amazing amount [45:10] in one night so he wrote a memo to [45:14] justify it and said there are some [45:17] problems with it you have to give to go [45:19] way further to reach the menu that's a [45:21] problem but we decided since there were [45:23] a command keys and he made it very easy [45:25] to have a single stroke command key in [45:26] this version this all-night version that [45:29] okay if you really wanted to go to that [45:31] menu item a lot you can hit the command [45:33] key on the keyboard instead and you [45:34] wouldn't move the mouse at all [45:35] so that solved that problem the other [45:37] problem was that if there were a lot of [45:38] windows open you wouldn't really be sure [45:40] which menu applies to which window and [45:43] sure enough that's still true today but [45:46] trade-offs you know why was it good it [45:49] was good because you got rid of all [45:51] those ugly cases of sticking out menus [45:54] and and also the dialog box that came up [46:02] when you had a command with parameters [46:03] could always go in the same place and we [46:05] had a problem before with the dialog box [46:07] coming up and covering up the menu half [46:08] the window and so on and so we could put [46:10] it in a standard place under the menu [46:11] bar [46:14] so this was all the result of his long [46:16] night of invention and then a couple [46:20] more examples we could put some global [46:22] commands in the menu before we didn't we [46:24] hadn't figured out yet we were to put [46:25] the global commands they didn't really [46:26] go anywhere because every menu was in a [46:29] window but now having a menu at the top [46:30] we could have global commands like you [46:33] know shutting down or whatever and then [46:35] we could widen the title tabs because [46:37] the menu didn't take up room at the top [46:40] of the window okay now we're in February [46:44] 81 so we've leaped ahead now several [46:46] months we're all programmers are busy [46:49] implementing stuff they're designing an [46:51] operating system telling us that we're [46:53] holding up the project when they're [46:54] still designing the operating system and [46:56] where the yep I was in charge of the [46:57] applications group and we were the [46:59] reason the schedule is behind schedule [47:00] we the project was behind schedule even [47:03] though they still were designed the [47:04] operating system so I wrote a memo for [47:10] other people who were going to help out [47:12] with user testing and I read men made [47:15] guidelines for user interviews so never [47:17] argue with each other in front of the [47:19] interviewee after they leave you can [47:20] shoot each other doesn't matter but now [47:22] well the not well the subjects there [47:24] don't patronize a subject don't show off [47:27] your knowledge I wrote this because I [47:28] would be bringing engineers into the [47:30] room and I'd sit him in the back and the [47:33] user would struggle to do something and [47:35] the engineer would run forward jump out [47:37] of the chair run forward grab the hand [47:38] of the person and say it's easy you just [47:40] do this and even though they still were [47:45] designed the operating system so I wrote [47:50] a memo for other people who were going [47:53] to help out with user testing and I read [47:56] men made guidelines for user interviews [47:59] so never argue with each other in front [48:00] of the interviewee after they leave you [48:02] can shoot each other doesn't matter but [48:03] now while the not while the subjects [48:06] there don't patronize a subject don't [48:08] show off your knowledge I wrote this [48:10] because I would be bringing engineers [48:11] into the room and I'd sit him in the [48:14] back and the user would struggle to do [48:17] something and the engineer would run [48:18] forward jump out the chair run forward [48:20] grab the hand of the person and say it's [48:22] easy you just do this [48:23] and I go no you don't get it so we tried [48:28] gags we tried all kinds of things but [48:30] finally I said look I'll let you in the [48:32] room if you if you you know observe [48:35] these rules don't plant the answer take [48:37] turns asking questions if there's [48:39] several of us there so we get different [48:41] we may each see different things and [48:43] mainly try to get them to do the talking [48:45] this is not a lecture by you this is a [48:47] test of them and you want them to [48:49] verbalize all they possibly can so [48:53] difficult thing that would happen is we [48:55] bring somebody in to prove that the [48:58] user-interface thing they put in was [48:59] absolutely right and we were totally [49:00] wrong and then the end user would [49:03] usually prove we were both wrong it was [49:05] hard to both four things were hard to [49:06] use and then we'd have to go back and [49:08] redesign it or half the time the user [49:10] would say well why doesn't it just work [49:12] this way and we look at each other [49:14] sheepishly and fix it here was an [49:17] interesting one for those of you who do [49:18] user testing you don't if you're not [49:21] named things you don't just say what [49:23] would you call this people paralyzed [49:24] like oh you're asking me to invent a [49:26] name they just get totally paralyzed [49:28] they can't think of a name but do you [49:30] say something like if someone were to [49:32] bring you this if you wanted someone to [49:34] bring you this what would you say bring [49:35] me the and then people would come up [49:38] with something it actually worked pretty [49:39] well so people have similar techniques [49:42] I've heard for other things [49:46] April 3rd 81 well at this point they're [49:49] starting to get very nervous about the [49:50] schedule the operating system design was [49:52] done I think and so we were that we were [49:54] holding things up and they decided the [49:57] problem was that we're these engineers [49:59] instead of just writing code like like [50:00] good sheep we're going in and you know [50:02] worrying about whether it was usable or [50:04] not so they decided to take all power [50:08] away from us and put all the [50:10] decision-making in to a council so who [50:12] was on the council first person was the [50:15] division controller in finance second [50:18] one was the VP of Sales who was always [50:20] on the airplanes third one was the head [50:23] of publications for Lisa which was a [50:24] good idea fourth one was kind of the [50:28] architect of the group that was a good [50:29] idea and the fifth one was somebody in [50:31] product marketing who you saw had made [50:33] comments before that were pretty good [50:34] ones so I was looking at this going okay [50:37] maybe we can live with this but the main [50:39] thing they did that was very good as we [50:40] instituted a process for what to do if [50:42] you had a user interface issue don't [50:44] spend eight hours arguing with each [50:46] other [50:46] write it up make your points get back to [50:48] work and then we have a process for [50:50] dealing with it but the council will [50:52] rule by majority vote so I think what a [50:56] way to design a user interface by [50:58] majority vote of the controller the [51:00] sales VP okay [51:01] [Music] [51:04] but we started this motivated those of [51:08] us who decided we had to do this the [51:10] right way to actually run more user [51:12] tests as we thought well maybe we can [51:14] overwhelm them with facts and that'll [51:16] overcome this reliance on on votes of [51:19] committees so Chris Dewar I can't [51:23] remember Wallis Judd I think Wallis [51:25] maybe you've worked at Xerox before this [51:26] I can't remember these are two people [51:28] that got involved with user testing the [51:30] filer is what you think of them as the [51:31] finder today and they ran some tests and [51:35] came up with all sorts of comments I've [51:37] underlined a couple here like there [51:38] needs to be a way to select multiple [51:40] icons at once while they weren't icons [51:42] yet even but ways to manipulate multiple [51:45] things at once [51:48] but basically after making some comments [51:51] they said you know this is a good idea [51:53] they're their own personal experience [51:54] with testing was he hired a testing firm [51:56] you spent a lot of money [51:58] three months later you came back with [51:59] test results and then you did some [52:01] things and he did it again you know it [52:03] took forever and they said you know or [52:05] they used or they or they would take a [52:08] book and give it to a subject have the [52:09] user read the manual try out the manual [52:11] videotaped the whole thing and and she [52:14] said you know this wasn't bad just [52:15] sitting down next to the user and having [52:17] a dialogue with the user trying to get [52:19] the user talk and express what they're [52:20] doing is not a bad way to do it so that [52:24] was good that we we got the the people [52:27] doing the user testing to adopt this [52:29] much simpler and cheaper paradigm we [52:33] tape recorded the sessions and they [52:34] found that useful they went back and [52:36] listened to the tapes and however the [52:39] tape for hard to hear because the people [52:41] in the room were making noise so they [52:42] asked the observers to be quieter I'm [52:46] gonna have to remove these from the box [52:47] now [52:49] it starts going a little quicker now but [52:55] one problem she said was that we're only [52:56] testing Apple employees we would get [52:58] Apple employees the day they took the [53:00] job the day they started work we'd get [53:02] them in orientation the person running [53:04] orientation would say well after [53:05] orientation you'd go straight to work or [53:07] you go you know be a user test subjects [53:10] and hey you get out of work for a few [53:12] more hours so we got a lot of people to [53:14] come over and the user test subjects and [53:19] almost all of them had very little [53:21] computer experience because although [53:22] Apple would have liked to hire people [53:23] with a computer experience in those days [53:25] there weren't very many so and here's a [53:28] typical schedule one it was the we [53:31] weren't trying to - an hour any more one [53:33] person at a time one each day nine [53:36] o'clock one o'clock 3 o'clock much more [53:38] civilized and and we had a checklist [53:44] that the tester went through before each [53:47] session have your mind of the subject of [53:51] whatever I have no idea whatever they're [53:54] supposed to remember there's some list [53:56] is there coffee available do you have a [54:00] blank questionnaire ready for the person [54:01] because we haven't fill out a [54:02] questionnaire at the end but you have [54:04] the checklist ready have you rewind the [54:06] tape have we really have we rewound the [54:09] tape for this talk today have you [54:11] rebooted because it crashed if you [54:13] didn't are the cue cards in the testing [54:16] room etc after each session did you [54:17] cover up ELISA again because the room [54:19] had a window and at night you could see [54:21] in the window and see the secret Lisa [54:22] machine you'd close the blinds for [54:25] double measure etc etc so we had a lot [54:29] of things to remind the tester of al [54:31] that's a good idea if you ever run user [54:32] tests have a checklist now Wallace the [54:35] guy who received the last memo wrote [54:37] this memo about some testing results and [54:42] he said he spent about an hour subject [54:45] which was pretty typical that's why I [54:46] like to do testing myself and he said [54:49] well some functions were still unclear [54:50] in particular seven subjects out of [54:53] how many doesn't say but not a lot well [54:59] not very many most of the subjects had [55:00] trouble with undo last command they've [55:02] never seen such a thing in a program [55:04] before and they just didn't quite [55:07] understand what it meant then there are [55:10] other ones they understood but they [55:12] didn't feel comfortable with somehow one [55:13] was printed copy one was mail a copy [55:15] well I believe the reason was that we [55:17] didn't have printers yet on the machine [55:19] and we didn't have email in fact we [55:22] never had email so we're probably just [55:25] shown these and not really couldn't use [55:26] them and so of course they didn't [55:28] understand them graphics editor user [55:33] testing this was Lisa draw which became [55:36] Mac draw later implemented by the same [55:38] guy actually mark cutter and we wanted [55:41] to test various things as it was as [55:43] confusing as that confusing can you use [55:44] what happens if you try to use rulers at [55:46] the same times at crosshairs is that too [55:48] many things on the screen and [55:50] considering all the widgets that are [55:51] there today in a photoshop or something [55:53] why were we worried but there was even [55:57] worried about whether people could use a [55:58] graphics program because well you know [56:00] people most people can't draw so they [56:02] wouldn't use a graphics program and we [56:06] also want to know the error rates and so [56:08] a lot of counting was being done and [56:10] looking at the tapes to see how many [56:13] times people made errors and try to [56:14] reduce the error rate so we're trying to [56:17] be sort of scientific even though we [56:18] were on this headlong schedule you may [56:20] have noticed as six months have already [56:21] gone by and we haven't shipped effect [56:23] it's about a year at this point ok so [56:26] June 81 Pat Marriot writes this memo [56:31] about validating the prototypes and trip [56:33] Hawkins at this point is that his wit's [56:34] end he says aren't we done with all [56:36] these decisions yet let's get on with it [56:38] why are we still talking okay here are [56:43] some of the issues should the arrows [56:45] point apart away from each other or [56:47] towards each other because after all the [56:49] text moves in the direction that's [56:51] opposite of the our direction we could [56:52] flip the arrows and make a point to each [56:53] other and I wrote up a comment here yeah [56:56] we can wait on September to test this no [56:58] hurry I wasn't in sync with product [57:00] marketing who wanted all the decisions [57:02] to be made because I knew that changing [57:04] this was a matter of [57:05] you know about three minutes of [57:06] programming so what was the hurry I'd [57:07] rather work on harder issues like you [57:09] know getting the software to fit in [57:10] memory or something and there were some [57:13] questions about clicking and folder [57:15] click well by the way they worked folder [57:17] when you see folder here we used to call [57:19] Windows folders I forgot to mention that [57:21] earlier might been confusing here every [57:23] window is a folder even a document when [57:24] there was a folder not just the ones on [57:26] the desktop and we wanted to test we [57:30] wanted to do some tests on that the [57:38] whole thing [57:41] the mirror thanks okay what was that [57:47] [Music] [57:49] okay [57:50] October 81 October 80 when we took the [57:53] Chris's advice to heart Chris DeRose [57:55] advice and we did outside testing 24 [57:57] people who did not work for Apple we're [58:00] done in in a one-way mirror room in Daly [58:03] City they didn't know what company it [58:04] was that was showing it you know blind [58:06] test the psychologist had their day we [58:09] got to do this you know right and this [58:12] was the thing that there was no way [58:14] we're ever gonna do this too expensive [58:15] takes too much time but at this point [58:17] product marketing was going well maybe [58:19] we better test this on real people and [58:21] we wanted to know whether they could [58:23] read the manual and install the hardware [58:25] and get the thing running by themselves [58:27] and it turned out that it was it was ten [58:31] minutes on average that a person could [58:33] from they trying to open the box it'll [58:35] time they get set up and running [58:36] something we thought that was pretty [58:38] good [58:38] those of you who are at Apple later know [58:41] that on the Mac it was even easier at [58:43] the beginning but as the Mac got more [58:45] and more developed that number going up [58:47] and when that numbers started getting [58:49] about an hour Jon ligase got extremely [58:53] upset and he ordered new user tests and [58:55] they ran user tests about that and got [59:00] the time back down to ten minutes again [59:01] but there were some bad years in there [59:04] it was very hard to open a Mac box and [59:06] figure out how to set it up two-thirds [59:08] of the users say they felt comfortable [59:09] using the product as a result of the [59:10] first experience and about half of the [59:13] people who were a half of the third that [59:15] were uncomfortable were people who [59:17] happen to run into crashes and so on [59:19] which probably affected their trying to [59:22] beat the clock on setting up the systems [59:23] kind of frustrating and we had a [59:25] question there they had to fill out [59:26] these this is the result of the [59:28] questionnaire so those numbers are how [59:29] many people had that answer and they [59:31] didn't think it would be that difficult [59:32] to set up before they started and when [59:36] after they did it they found that it was [59:38] very easy [59:41] all right now it's still at 1981 now I [59:45] should mention that the Xerox star was [59:47] announced that NCC or something National [59:50] Computer Conference I think in June of [59:52] 81 and the Sun Lisa people flew out [59:57] there got to look at it Bill Atkinson [59:58] went I believe and and Steve Jobs went [60:00] or maybe he sent bill and didn't go [60:02] himself I can't remember at this point [60:05] we had a guy named Greg spike letter who [60:07] had joined the group working for Ellen [60:09] old in the training lease of training [60:11] some of you may know Greg because he's [60:12] he's recently more recently been an [60:14] entrepreneur sold a couple of companies [60:16] and Ellen is sending a memo to various [60:20] people copy and Greg and [60:22] responsibilities charting for user tests [60:24] now that user interface counsel we [60:26] talked about before with the majority [60:28] vote I don't know if they ever even have [60:29] one meeting now we kind of overwhelmed [60:32] them somehow and by this time a few [60:34] months later we had have a new process [60:36] so the new process was that based on [60:39] some lecture we've all all went to bytes [60:40] a management consultant we were going to [60:42] have people with authority people with [60:44] responsibilities people who are [60:45] consulted people who were conformed and [60:46] basically product management hell they [60:48] had all the authority since since Ellen [60:52] worked for them and engineering and [60:55] training which is Ellen's group had all [60:58] the responsibility so we did all the [61:00] work and then product management would [61:02] bless it and say that hey February 1982 [61:06] year and a half is gone by engineering [61:10] user test this is a sample test we had [61:12] there's a write-up up a test we had a [61:13] standard form to write him up in now [61:15] we're getting real formal here not just [61:17] you know run into Steve Jobs after the [61:19] test and tell him what happened we were [61:21] we were writing you know formal reports [61:23] what the person did how they did I'll [61:27] skip over a little bit of this oh well [61:29] the person had a john org chart and here [61:32] not having a graphics program myself [61:33] that had printing working yet I was [61:35] doing it in the word processor and [61:37] drawing little org charts here but they [61:38] were really doing it with a with a [61:40] drawing program and by the way the thing [61:43] that went over the product marketing [61:45] people was when we gave them the drawing [61:47] program it was the first one to get [61:49] working [61:49] I had mark cutter just try to get it [61:51] really reliable and don't worry about [61:53] too many features and then we gave all [61:55] the [61:55] product marketing people elisa some [61:57] temporary operating system in the [61:59] drawing program that's it [62:00] and single tasking operating system at [62:02] that time and and they all started using [62:05] it to make foils and you could do tax [62:08] you could do boxes you know and they all [62:09] did foils and they fell in love with [62:10] ELISA and they even start to understand [62:12] the Lisa and gradually the complaints [62:14] started dying down and they start [62:16] trusting like maybe we knew we were [62:17] talking about so that was a very good [62:18] political move and I always made sure [62:20] mark gave him you know good stable [62:22] versions of the draw program they draw [62:25] floorplan and then at the end it [62:27] comments to make and you could see that [62:29] the comments were summarized and people [62:31] were basically really positive about [62:33] this program sometimes they were [62:35] complaints and we address them now this [62:38] particular test was I guess run by Greg [62:39] stack leather and me he probably ran the [62:41] test and I was in the room or sometimes [62:42] we switched off and he made our comment [62:46] which was that i-beam which was the [62:47] cursor that you used to select text when [62:49] the person would start typing that [62:50] little cursor was covering what they [62:51] were typing so he suggested that we get [62:53] rid of it well there was no mechanism to [62:55] get rid of it in the software but he [62:57] didn't know that and so it was good that [62:59] he was there and he suggested it and we [63:01] then implemented that and I can I [63:04] pointed out that the stretch handles [63:06] were a problem initially what Mark had [63:08] done was he studded the outside of your [63:11] object like every fourth pixel with a [63:13] little handle so big objects had you [63:15] know beads all the way around the [63:17] outside it was like a necklace and this [63:21] really confused the people and I [63:22] suggested we just had the four corners [63:24] and the four sides and that fall and [63:25] that is the way it ended up first I was [63:28] showing you all the good comments we had [63:31] a lot of stupid suggestions too and now [63:34] remember we had user test guidelines [63:35] before Greg wrote some new ones and here [63:39] he was trying to address this to people [63:43] who might have been used to formal user [63:47] testing and had never experienced what [63:49] he was calling development testing and [63:52] you know things you test after the fact [63:54] and things you test while you're still [63:55] in development so he made some [63:57] guidelines and they were interestingly a [63:59] little different from mine [64:00] a different level and I think I didn't [64:05] bring them just the fact that he did [64:09] okay all right good near the end here [64:14] excuse me may 18 2010 so Greg said we [64:25] should run development tests so we did [64:26] we ran development tests and I taught 30 [64:29] Apple employees over a period of several [64:31] weeks several different applications and [64:34] to see whether you know we were on the [64:36] right track and by this time people were [64:39] accepting this is a good approach [64:41] because it was a lot better to be [64:42] informed by a user test than to just see [64:44] who talked the loudest in an argument [64:46] who had the most political clout and [64:48] what I found was that the way we taught [64:51] it made a lot of difference you could [64:52] take the same user interface and teach [64:54] it a different way and people get real [64:55] confused or understand it and or make [64:59] more mistakes or fewer mistakes and [65:00] terminology made a difference also so we [65:03] then started a terminology project that [65:04] Ellen old ran which ended up and I many [65:07] slides I didn't bring on that and that [65:09] ended up with the file menu the Edit [65:10] menu etc and as you know today and the [65:14] various commands that were in them you [65:16] know choosing all the words for [65:17] everything that had pretty much survived [65:19] into the Mac let's say 95% of them [65:21] survived into the Mac and most than when [65:23] at the windows also so that was a very [65:25] healthy terminology exercise is it a lot [65:28] of testing and a lot of debating lettle [65:30] linguistic analysis and one thing I say [65:34] here is that after all these tests I [65:35] discovered a lot of things that could be [65:37] better but we do have to ship a product [65:39] and it's been a long time since I've [65:41] been a park so okay we'll ship a product [65:44] but couldn't we fix these in the next [65:45] release well little did I know there [65:51] would only be one more release and then [65:54] we had a process again where we were [65:57] going to be very careful about [65:58] prioritizing all the user interface [66:00] changes and measuring their scheduled [66:02] impact and being sure they were worth it [66:04] didn't have to be zero necessarily but [66:06] it had to be worth the worth the [66:08] scheduled impact [66:09] I think by this time people were really [66:11] realizing that our only differentiation [66:13] was ease abuse and it better be really [66:14] easy and then I went through some [66:17] problems this thing went on by the way [66:18] for about 30 pages so I'm just going to [66:20] show you one page cursor changes were [66:23] not consistent and they were cursors [66:26] changing shape everywhere the i-beam [66:28] wasn't the only one like no matter where [66:29] you went in the window you got a [66:30] different cursor shape and I thought you [66:31] know that's too many let's simplify that [66:33] we had double and triple clicks at that [66:35] time and some people it was the amount [66:39] of time between the clicks mattered and [66:41] you couldn't control it so I suggested [66:44] we had a preference item that people [66:46] could control that time which of course [66:47] is what you do today in the Apple's [66:49] mouse control panel and I also had some [66:52] comments about how you teach it and in [66:54] fact when I looked at that whole memo [66:56] I'd say there were at least as many [66:57] comments I made about how to teach it as [66:59] to what it is and then months earlier I [67:03] think it was really one month earlier [67:05] Gregg cycle Heather had pointed out that [67:07] the i-beam should disappear when you [67:08] type I don't know if I forgot or [67:10] whatever but I suggested the same thing [67:11] again or observed it and I propose we [67:14] hide the cursor and here in the margin [67:17] as I'm something I wrote later saying it [67:19] has been implemented if you worry about [67:25] the where we're wondering about the [67:28] cursor changing to a clock or an [67:30] hourglass various other things that was [67:33] something that was actually at Xerox [67:34] Xerox had that at Parc and the thing was [67:37] the way we did it was we would wait a [67:39] certain number of seconds and if the [67:41] operation wasn't done we would put up [67:42] the hourglass trouble was by that time [67:44] the operation was probably done so we or [67:48] some of the applications forgot to put [67:50] it up at all so we came up with some [67:52] clever algorithm for having it come up [67:54] automatically and and disappear at the [67:57] right time and all that sort of stuff [67:59] now here's the big change the star had [68:02] come out a year earlier than this and we [68:04] were all set we were all told by [68:07] management and ourselves don't pay any [68:09] attention to that we've got a product to [68:10] ship but in everybody's heart they kind [68:13] of felt like you know most of the lease [68:15] is easier to use than the star but [68:17] there's one thing about the star that is [68:19] really really nice which is those the [68:22] little icons on the desktop there was I [68:24] con envy that was very serious and we [68:27] weren't allowed to work on it but around [68:30] March of that year some of the guys got [68:33] so troubled by it that they started [68:36] working at home on weekends on an iconic [68:40] filer we called it and a person was a [68:43] big secret and they started letting [68:44] people in on a little bit at a time and [68:45] finally everybody found out about it and [68:47] there was a major uproar that people [68:49] would dare to make changes at this late [68:50] stage but they'd already implemented it [68:53] and so you couldn't complain about the [68:55] schedule impact and the person writing [68:58] the manual thought it was kind of a good [68:59] idea so she kept saying it wouldn't [69:01] affect her schedule and so nobody knew [69:07] what to do so I said so I made a deal [69:08] with trip Hawkins and Wayne rosing who [69:11] was the engineering manager at that time [69:12] we'll run user tests and let the users [69:14] decide so I ran tests and you know what [69:17] it turned out that the interface we have [69:18] which I won't bother to show you but it [69:20] was kind of a more like find file it's [69:22] the closest thing I can think of was [69:25] actually equally good in terms of ease [69:27] of learning equally easy to use same [69:30] error rate very low people understood [69:33] both there was no difference and we [69:35] already had one so why did we change and [69:37] then the last question I asked everybody [69:39] is which do you like better and they all [69:41] like the picture one better and so we [69:44] made a decision that nothing to be [69:46] nothing to do with ease-of-use nothing [69:48] to do with these are learning nothing to [69:49] do with error rate it wasn't human [69:51] factors decision at all in the [69:52] traditional sense it was decision based [69:54] on what customers liked and there's a [69:58] whole history I won't go into here about [69:59] the icons they didn't actually come from [70:00] the star they came from IBM did I'm not [70:03] gonna get into that long story you can [70:05] read the Proceedings of Apple versus [70:08] Microsoft lawsuit or something to find [70:09] that out [70:11] okay so this is my last slide here so [70:15] and this was a memo that included on it [70:22] Chris Espinosa who was in the Macintosh [70:25] group at that time and the Macintosh [70:27] people who had been doing a totally [70:28] different user interface at some point [70:29] decided they really ought to do some [70:31] subset of lease user interface instead [70:33] and so they wanted to get a lot of ideas [70:36] from us as they design their user [70:38] interface so we started copying the Mac [70:40] people on it and with that September 82 [70:44] I'll turn it over to Chris yes I go show [70:54] the tape team now you use one for both [70:59] why don't we if you want we can talk [71:00] about that after the talk I forgot that [71:02] I had a videotape here is that monitor [71:04] turned on what I've got here is just 30 [71:12] seconds because the tape is really bad [71:14] of one of the very first user tests in [71:16] July of 1980 and the one I have here [71:20] bill and I took turns that this what I'm [71:22] going to be showing you is Bill with a [71:24] subject you can't see the subject most [71:27] of the tape all I can see is a [71:28] out-of-focus back of Bill's head but I [71:30] found half a minute where you can [71:31] actually see the screen of the Lisa so [71:33] it's really quick you better get a good [71:34] look and I think it's set up let's try [71:41] and is there audio on [71:45] I tied you up late have you type playing [71:49] with that [71:51] [Music] [71:52] option so here's that menu at the bottom [72:01] of the window this is really early and [72:04] there's that highlighted selection the [72:05] person made with the mouse and he just [72:08] explains something very simple and she [72:10] didn't understand it so he's starting [72:11] all over now we get to see his hair so I [72:15] think we'll stop okay [72:20] so there's nothing really much to get [72:21] out of that but I did promise to show [72:23] some early Lisi user tests now I've done [72:25] it [72:26] given the time I think we're gonna save [72:28] questions to the end and let Chris take [72:31] off on one his great thanks very much [72:36] [Applause] [72:55] as Larry said the the work that we did [73:00] on the Macintosh human interface tough [73:01] tailed with the end of the the very [73:04] fruitful period of Lisa human interface [73:07] design I can't I cannot believe how much [73:09] work they went through in a short period [73:12] months in the summer of 1982 put [73:16] together what we still see today in the [73:18] human interface of the Macintosh and the [73:21] human interface and Windows about what [73:24] was really interesting to me was that [73:27] when Larry first proposed this talk to [73:29] educate some people new people at Apple [73:31] from some companies we'd acquired on how [73:35] the user interface came to be that that [73:39] a lot of the people he was referring to [73:41] a lot of the people who were Co copied [73:43] on some of the documents a lot of the [73:44] work that they drew on really had [73:47] nothing to do with the graphic user [73:50] interface but had to do with a [73:52] long-standing user interface community [73:55] at Apple that had evolved in a totally [73:58] separate organization for totally [73:59] separate strain and that was the Apple 2 [74:02] in the Apple 3 human interface effort [74:04] that was going on in the personal [74:06] computer systems division which was by [74:08] that time physically remote down in the [74:10] big black triangle shaped building at [74:12] the intersection of 280 and Lawrence [74:14] Expressway called that triangle building [74:16] or by then the Bermuda Triangle because [74:18] it's where the Apple 2 group had been [74:20] moved to die the the thing that you [74:24] really have to understand about that the [74:26] crucial difference between the Lisa [74:30] Macintosh human interface effort and [74:32] what was going on in the Apple 2 group [74:34] was not the difference between the [74:36] graphic human interface and text-based [74:37] human interface though that was an [74:39] important part of it the crucial [74:41] difference was that in the Lisa and the [74:42] Macintosh the engineering groups were [74:45] completely integrated in and the driving [74:48] forces behind the making the computer [74:51] easier to easier to use whereas in the [74:53] Apple 2 the evolution of that had been [74:56] that the the impetus for making the [75:00] computer easier to use [75:01] which programs were selected to make [75:03] that had come from the publications [75:06] Department the training Department and [75:08] the department doing demonstrations for [75:11] in-store retail sales our effort and I [75:15] was a member of that group in our effort [75:16] was primarily to mask the complexity of [75:19] the real underlying software that we [75:21] were already shipping by putting sugared [75:24] user interfaces on top of the real [75:26] interfaces and by putting training [75:29] programs on top of the real computer [75:31] programs and this was remember the Apple [75:34] Computer by 1980 boy we've been around [75:36] for three years we had a long history [75:39] behind us in the personal computer [75:40] industry and we had a lot of accumulated [75:43] legacy software that we couldn't just [75:45] haphazardly change we really had to work [75:47] on it so one of the documents that I [75:51] have here is a document I've got it on a [75:57] video here although I don't think it'll [75:59] be that easier easy to read manuals [76:08] consistent and provide a consistent and [76:11] familiar and productive experience to [76:13] readers of manuals Bruce [76:22] this is the this is that document and [76:26] this is the change history of the Apple [76:27] to human interface guidelines that show [76:30] the first draft Bruce tag Nazim he [76:32] claims to have written in in September [76:39] of 1978 second draft in March of 79 [76:45] third draft in mid 1980 fourth draft [76:48] with Steve Smith in early 1981 and then [76:51] it got into the Macintosh group in 1982 [76:54] I started working on it in late 82 and [76:57] that's when I incorporated many of the [76:59] things from the Lisa efforts and then it [77:02] moved back over into the Apple 2 group [77:04] to cover the Apple 2 graphic user [77:06] interface but it originally started as [77:08] an apple to text human interface [77:10] document and it came originally from [77:14] Bruce's efforts with JD Eisenberg [77:17] writing an application called Apple [77:19] presents Apple which was the main [77:21] in-store or first user demonstration [77:25] program for the Apple 2 Bruce started [77:28] that well I don't know where Bruce [77:29] started out but when we when we [77:31] encountered Bruce Takenaga noesy me in [77:33] his long and checkered career he was the [77:35] proprietor of a computer store in San [77:37] Francisco which is where the apple core [77:38] of San Francisco used to meet and that's [77:40] how he got into the Apple community by [77:42] selling Apple computers so he had [77:44] frontline experience of what happened [77:46] when a person encountered a personal [77:48] computer for the first time when he came [77:51] to Apple he started writing demo [77:52] programs with JD Eisenberg and one of [77:55] the things that they did was they tested [77:57] on real users in real situations where [78:00] you bring somebody who's never seen the [78:02] computer before much like a the Lisa [78:04] group was testing people off the street [78:06] or new employees put them in front of [78:08] this program and gave them no advice [78:10] whatsoever I'm going to read Bruce tends [78:14] to philosophize a lot in this so it's [78:16] not going to be as useful to put up [78:18] slides but I'm going to read to you some [78:20] of his experiences from the [78:30] here we go from user testing our testing [78:36] method is as follows we set up a room [78:38] with five to six computer systems we [78:40] invite groups of five to six users at a [78:42] time to try out the systems often [78:44] without knowing that it is the software [78:46] rather than the system we are testing we [78:49] have two of the designers in the room [78:52] any less and they miss a lot of what's [78:54] going on anymore the users feel as [78:56] though there's always always someone [78:57] breathing down their neck the initial [78:59] ground rules are that no questions will [79:01] be answered as by the time the formal [79:03] testing begins we can supply a draft of [79:05] the manual usually by the second group [79:07] some glaring defects in the interface [79:09] have shown up and we have to give them [79:10] help getting past the stumbling blocks [79:13] 95% of the stumbling block blocks found [79:15] are found by watching the body language [79:17] of the users watch for squinting eyes [79:20] hunched shoulders shaking heads and deep [79:22] heartfelt sighs when a user hits a snag [79:27] he will assume it is his fault he will [79:29] not report it he will hide it make notes [79:31] of each problem and where it occurred [79:33] question the users at the end of the [79:35] session to explore why the problem [79:37] occurred you will often be surprised [79:39] what the user thought the program was [79:41] doing at the time he got lost here in [79:45] follows a true anecdote which [79:47] illustrates how difficult the most [79:48] simple human interface issue can be and [79:50] why thorough testing on real people is [79:52] so important as we tune in it's so easy [79:56] to entertain a crowd just by reading [79:57] something Bruce wrote as we tuned in the [80:00] authors of the software both of whom [80:02] pride themselves on clever interface [80:03] design have anguished for hours over [80:05] difficult passages in their program it [80:07] was to turn out there it was to turn out [80:10] their guesses were quite accurate [80:12] instead difficult passages it was the [80:13] simplest question of all the cause of [80:15] the problem an apple presents the apple [80:18] 2e the training program for teaching [80:20] fundamentals of using the new Apple 2e [80:22] find out if the user is working with a [80:24] color monitor User Profile new owner [80:28] customer and computer store or member of [80:30] a class learning how to use an Apple [80:32] computer test User Profile customers and [80:34] computer store non computers in the [80:36] classroom environment friends and [80:37] relatives first design a color graphic [80:40] is displayed on the screen [80:42] are you using a color TV on the Apple [80:45] anticipated problem those who are using [80:48] a monochrome monitor in a classroom or a [80:50] computer store situation wouldn't know [80:52] whether the monitor was black and white [80:53] or was colored with the color turned off [80:55] first attempt to color graphics [80:57] displayed prompt is the picture of of in [81:00] color 25 percent failure rate reason as [81:06] anticipated but incorrectly overcome [81:08] those seeing black and white thought [81:10] their color might be turned down they [81:11] didn't answer the question wrong they [81:13] turned around and asked one of the [81:14] authors whether the monitor in question [81:16] was color or not a decision was made the [81:19] authors could not be supplied with the [81:20] disk second attempt a smaller graphic [81:24] with large letter words and their own [81:26] vivid colors was substituted green blue [81:28] orange magenta which were the only [81:30] colors the Apple 2 can display prompt [81:33] are the words above in color color [81:34] failure 8 color TV users none [81:37] black-and-white monitor users none green [81:39] screen monitor users 100% this is why it [81:46] pays to have a variety of configurations [81:48] in your test suite third attempt the [81:51] graphic remain in the same failure rate [81:53] prompt are the words above in more than [81:56] one color failure eight color TV users [82:01] none black and white monitor users 16% [82:04] green screen monitor users 50% reason [82:08] the black and white monitor users who [82:09] answered incorrectly admitted they did [82:11] so on purpose [82:16] 50% of the green-screen folk considered [82:19] that they were looking at both black and [82:21] green two colors and answered the [82:23] question accordingly fourth attempt same [82:29] display of graphic and color text prompt [82:31] are the words above in several different [82:32] colors are the words above in several [82:35] different colors failure rate color TV [82:38] users none black and white monitor users [82:40] 20% green screen monitor users 23% by [82:44] this time the authors were prepared to [82:46] supply everyone who bought an apple with [82:47] a free color monitor just so we would [82:49] not have to ask this question it turns [82:53] out about 20% of the people we're not [82:55] really reading the question and we're [82:57] responding to our the words above [82:58] several different colors oh yes of [83:00] course green violet red there's several [83:01] different colors let's move on fifth [83:04] attempt same display of graphic and [83:06] color text prompt do the words above [83:08] appear in several different colors [83:11] failure eight none in it in case it [83:17] appears the authors were simply dull [83:19] fellows be it known that this was a [83:20] fully interactive training program in [83:22] excess of a hundred K of code remember [83:25] it was 128 K machine so and this was the [83:29] only interface issue that required more [83:31] than one correction it clearly [83:32] exemplifies how even the most careful [83:34] designers can totally miss when guessing [83:36] at how users are going to respond so a [83:40] reading from Bruce cognizant the Apple 2 [83:47] project had started out well the Apple 2 [83:50] wasn't really a project it was a [83:51] collection of projects we started out [83:53] with a number of pieces of software that [83:56] had our cherished angle bracket or [83:58] square bracket prompts by the time we [84:01] got around to the Apple 2e in the Apple [84:03] 3 we developed a more or less text [84:06] windowing interface called the file card [84:09] metaphor where we used special [84:11] characters in the character generator [84:12] ROM to do something like the file card [84:15] interface in the Lisa with pick one two [84:19] three four five six menus and you use [84:22] the Escape key to back out through a [84:23] hierarchy and press [84:26] numbers 1 2 3 4 5 6 to advance to the [84:28] next level it was a hierarchical spatial [84:32] text driven keyboard ribbon user [84:34] interface it didn't use the mouse it was [84:36] very successful for what it did we [84:39] ensured consents consistency across many [84:41] applications all the applications that [84:44] Apple implemented as well as third-party [84:47] applications for example if anyone was [84:49] familiar with quark catalyst quark [84:52] they're the people who make pork Express [84:54] now they made the original hard disk [84:58] manager for the Apple 2 in the Apple 3 [85:00] and it used the same interface it had [85:03] consistent use of the keyboard keys the [85:05] open apple always meant the same thing [85:07] in in in different applications and so [85:09] even though it was a text interface it [85:12] had many of the underpinnings of the [85:14] consistency of the graphic user [85:16] interface of the Macintosh and it was [85:18] driven by the exigencies of user [85:22] training which was my mother's group [85:26] because the less time we had to spend on [85:28] user training the cheaper and faster it [85:30] was and if the software were consistent [85:32] the training went more easily it was [85:35] driven by the [85:35] the exigencies of publications which was [85:38] the group I was running and one of the [85:40] problems we faced in publications was [85:42] that having not invented desktop [85:44] publishing yet we had six weeks minimum [85:48] from film to printers which was usually [85:50] the time that was reserved to write or [85:53] finish the software and we often had to [85:57] be finished with the manuals several [85:59] months before the product shipped which [86:02] in the software wasn't finished at that [86:04] point so in order to have manuals that [86:08] accurately reflected what the soccer was [86:10] going to do we had to have the [86:11] programmers tell us what the user [86:13] interface was going to be and then in [86:15] going through that with the programmers [86:17] having them do it the same way that [86:19] other applications did it gave us a more [86:21] full idea for okay it's going to do this [86:23] it's going to do this it's going to do [86:25] that if they followed some standard or [86:27] some guidelines in fact what Bruce did [86:30] before writing the Apple to human [86:32] interface guidelines and what the origin [86:34] of this document was was in fact a [86:39] publications style guide which was how [86:43] we wrote manuals and how we explained [86:45] portions of the human interface and [86:47] explained portions of how you use the [86:50] computer and by using consistent [86:53] explanations that drove consistent [86:56] design and in some of the applications [86:58] so that was some the origins of user [87:01] testing and of of consistency of new [87:05] user interface design in the Apple 2 [87:08] group as I said it moved into the the [87:11] Lisa group started with a separate [87:13] separate angle from which Larry talked [87:16] about coming from the Xerox PARC and the [87:19] to basically fused in the Macintosh [87:21] group where we had the the Lisa just [87:25] benefits of the years of Lisa user [87:27] testing experience in the massive amount [87:29] of design that went into their graphic [87:31] user interface it user interface plus a [87:34] lot of the Democratic grassroots issues [87:39] that had come up through the Apple to [87:41] remember Lisa was only dealing with [87:42] seven applications that was all you've [87:44] got on ELISA the Macintosh was designed [87:47] like the Apple Q is something where you [87:49] had many many applications from [87:51] third-party developers and so we took [87:53] the Lisa user interface grafted it on to [87:56] the guidelines that had come out of the [87:57] Apple two style guide and Apple to [87:59] guidelines efforts and published that [88:01] for third-party software developers to [88:03] use as style guides for their own [88:05] applications I remember very very very [88:08] clearly that one of the massive [88:12] controversies around the development for [88:14] the Macintosh circa 1990 1980 to 1983 [88:18] was developers would come up to us and [88:21] say you know if you make the user [88:23] interface consistent and if you put all [88:26] that software and ROM that makes it you [88:28] know if you make it hard to write to the [88:31] screen directly so that we have to use [88:33] your user interface software to talk to [88:35] the user how are we ever going to make [88:38] our applications unique and stand out [88:40] and be different from each other in the [88:41] marketplace they found a way I'm very [88:43] happy but the the human interface and [88:46] the idea of a consistent human interface [88:48] much less and graphic one was very very [88:51] controversial [88:52] software developers and only by having [88:54] the user testing under our belt to show [88:57] them that hey this is going to add [88:59] significant value to your product by [89:02] making your product easier to learn and [89:04] easier to use especially for people who [89:06] already know another application where [89:08] we able to really convince them that a [89:11] consistent graphic user interface was a [89:12] good thing to have I want to fast [89:15] forward a little skip through the early [89:17] years in the Macintosh and go to a tape [89:20] that I dug up from the Apple library of [89:22] the of some user interface testing that [89:25] that shows how amusing user interface [89:28] testing can be in the kinds of [89:29] situations and far-flung places that [89:31] members of our our glorious human [89:33] interface group went to find the truth [89:36] about what real users would do and this [89:39] is a tape of a couple of our user [89:42] interface designers Laurie ver tell me [89:44] and one other person I may come up with [89:48] her name oh I don't think it was Gita [89:51] traveled to France to parts dealership [89:55] for Renault automobiles who were [89:57] deploying a new automotive parts catalog [90:00] based on HyperCard and HyperCard being a [90:03] free-form [90:05] toolkit for designing new software [90:08] interfaces presented an entire raft of [90:11] new problems in human interface design [90:12] and then they actually went to France to [90:15] test auto mechanics in their own [90:18] environment and I'm going to play that [90:19] tape for you now yeah I'll turn it on [90:43] it might have been cake tamal yeah okay [90:47] Thank You Annette was that Annette oh [90:50] it's joy hi joy [91:14] you know okay this is hard [91:30] the first part of the user test was to [91:33] test users attempting to fill out an [91:34] order form using declarant even though [91:38] [Music] [91:39] these are the order and estimate forms [91:41] that the mechanics currently use and the [91:50] repair Mendel has instructions on how to [91:52] read the car [91:54] Katie's daleney teske procedure and the [91:57] cows to be recovered in an attempt all [92:01] the researchers were interviewed as a [92:02] mechanical educator in French [92:08] [Music] [92:10] if you have trouble with some of the tax [92:12] system to test Katie clips that we help [92:32] us evaluate results later I wouldn't a [92:35] test session Cleveland attended work [92:42] with the paper helped us understand how [92:43] it referred to using information for [92:45] example exact the fourth on top of the [92:47] catalog with their pages while [92:49] researching information research [92:51] techniques helped us to make design [92:53] recommendations for searching that the [92:54] electronic version default on process [92:59] once we finished testing the curt [93:01] affordability seizure we asked intended [93:03] to solve the same problem in the [93:04] documentation electronic system at this [93:09] point in our test easy no strike almost [93:11] 10 minutes simply respect the system [93:13] hate fighting scripts the easy to do is [93:16] click on the [93:18] system interpret horns no you should [93:24] explain the pop-up menu that lies who [93:26] lives there iconic kate says no visa [93:29] quickly I kind of like nothing about how [93:31] these pop-up menus in the initiative [93:32] dialog box which explains to him and [93:34] musical down on the icon question [93:40] McKenna didn't receive a lock box before [93:41] must refuse not only about the message [93:43] to the side of it but that has do with [93:45] them finally analyzing this click on OK [93:48] to get rid of it [93:53] [Music] [93:59] the ocean transportation that puts on [94:01] many Tibetans and the many to the left [94:03] of the screen unfortunately one of the [94:05] menu items worked at this point because [94:07] he's not so about the appropriate [94:09] vehicle identification to actually start [94:12] work session tries to smile economists [94:16] anniversary because once again he brings [94:18] up the ballot box itself and hold down [94:20] on the other side this time you didn't [94:23] see that he must become your [94:24] preprocessors clicking around the [94:26] strategy real assistant commentators [95:12] [Music] [95:31] so that just uh I think is an [95:34] illustration that of two things one that [95:36] bad design knows no bounds and and two [95:39] that that you never get a user interface [95:43] right and that user testing from the [95:47] earliest times when you have a a totally [95:50] unsaturated market people who've never [95:52] seen personal computers before much less [95:54] mice keyboards screens things like that [95:57] to today when we assume that anybody [96:00] who's ever you know been in Western [96:04] society has had to have encountered a [96:06] personal computer at some point and [96:08] knows the basics of pointing clicking [96:11] dragging pressing what a file is what a [96:13] document is how to print why to print [96:16] what a floppy disk is I mean II I I [96:19] still find it surprising that we don't [96:22] talk about sectors and cylinders anymore [96:25] on discs which was one of the main [96:26] things we had to explain the 1978-1979 [96:30] because there was some reason you needed [96:33] to know that I forget why but yes but [96:38] that some things never go away and that [96:42] having to test new designs and test your [96:46] assumptions of what your audience knows [96:48] is pretty much eternal so at that point [96:51] having run pretty late I think Larry and [96:53] I will take a few questions and I think [96:55] that we are going to take free liberty [96:57] to defer to several people in the [97:00] audience who are noted in Apple hue [97:02] interface history I see joy Mountford [97:05] and Annette Wagner back there who've [97:07] been instrumental in human interface [97:09] groups in the past and if there are any [97:11] others and if you have strong opinions [97:13] disagree with us have more information [97:16] than we're able to supply supply please [97:19] chime in and Larry do you want to pass [97:22] the mic around so people can ask [97:25] questions in the mic okay oh hello that [97:32] works well your clips nope here Larry I [97:37] wonder if you could comment on the story [97:38] that's often told that Apple ripped off [97:41] the Xerox PARC work I know Jeff Raskin [97:44] has refuted or denied that but it's such [97:46] a popular story could you go on record [97:48] as giving your perspective yeah well I [97:51] actually showed at the beginning of the [97:53] talk picture of the small talk interface [97:55] to see that in fact the early user [97:57] interface designs we're very close to [97:59] that the look of the windows in [98:01] particular and the icons in the desktop [98:02] but it evolved over time and you know [98:07] that menu move to the top of the screen [98:08] and so on if you actually look at either [98:10] a Xerox star or a small talk screen and [98:12] then look at Alisa or Mac I think you'll [98:14] see a lot of differences what was taken [98:17] was the concepts the concepts that there [98:20] ought to be overlapping windows that [98:22] there ought to be direct manipulation [98:24] and so on but the rock star for example [98:27] didn't have the concept of dragging [98:29] things and it had two button mouse you'd [98:31] click one place and then click another [98:32] place it didn't have a menu bar in fact [98:35] it was only one menu that was added late [98:36] in the development and it you know but [98:41] some things were similar they were there [98:43] was a horizontal and a vertical [98:44] scrollbar so certainly the concepts came [98:47] largely from there but as you see some [98:49] of the concepts came from other things [98:51] from HP systems UCSD from Apple too from [98:54] some work that was done at IBM that I [98:56] didn't talk about today that was [98:57] published around the late 70s so there [99:02] were a lot of origins for it I think the [99:04] Xerox work had a lot to do with it but [99:06] usually when the if you sat down to try [99:11] to use a star or small talk you would [99:13] find that there were I think more [99:14] differences than some [99:15] clarity's in what you would actually see [99:17] and do [99:31] question is the user testing we showed [99:33] for the Lisa had to do with novice users [99:35] and we the question was whether we [99:36] tested for how people our culture ate it [99:38] over time [99:40] well the system remember from the very [99:42] first page of the user interface [99:43] guidelines Bill Road was targeted at [99:45] novice users that was the target which [99:47] was about everybody in those days and we [99:50] did have some theories about how people [99:54] would you know use command keys as they [99:56] got more expert and so on but we didn't [99:59] run user tests one reason we didn't was [100:01] because it would have taken a long time [100:02] to get people up to speed so what we did [100:06] was we just used kind of ourselves I [100:08] don't mean the engineers but people who [100:09] worked in the Lisa division who had [100:10] leases like people in product marketing [100:12] they became expert after a while and [100:15] they would start telling us that things [100:17] were too slow or too hard or whatever [100:19] and that's how we got that kind of [100:20] feedback just from people inside and I [100:24] think it's more relevant today to check [100:27] for those sort of things than it was [100:28] back then when everybody was you know [100:30] 95% of the people were novices one of [100:32] the constant tensions and this was true [100:34] on the Macintosh as well especially [100:36] because we had the benefit of the Lisa [100:38] work before us and some of the the Lisa [100:40] machines was the constant tension is [100:42] that the people who are designing are [100:44] almost always by definition expert users [100:47] and will often overlook that what they [100:49] think is obvious is not at all obvious [100:51] to a novice user and so there there's [100:55] constantly the the dilemma which you've [100:58] seen historically in Mac system software [101:00] that the expert users want to put in the [101:03] features they want to use but the people [101:05] who want to keep this system pure for [101:07] the novices want to resist those and and [101:09] if you're lucky you get a system that is [101:11] easy to approach for the novice and [101:13] gradually unfolds itself for the expert [101:15] and if you're unlucky you get a lukewarm [101:18] mediocrity between the two where it's a [101:20] little too complex for the for the [101:24] beginning user to understand but still [101:26] not nearly powerful enough for the [101:27] expert user and and some of our designs [101:29] and some of the industry designs have [101:31] been one gradually unfolding and others [101:33] have been just plain mediocre [101:38] have a survey ssin and then a question [101:40] Larry and I have known each other for [101:42] years and it's interesting to me that [101:48] for one thing you folks weren't away [101:51] aware of the similarity to the word [101:52] start commands had already existed and [101:54] the word star editor for you know copy [101:57] cut paste kind of things but also I [102:00] think the the word assumption is is key [102:04] and what you just said is where [102:05] incorrect people assume that as they're [102:07] developing something that they know the [102:09] best way to develop it rather than go [102:10] outside and get other information you [102:13] know one of the things that we've I've [102:15] seen as a software person in the past [102:18] having to do work for people for money [102:20] so that they expect us to have something [102:22] done by a certain time I mean not for a [102:24] company that I'm working for but for as [102:26] a consultant is that they really do [102:28] expect the thing to work the way their [102:30] people want it to work and there you [102:34] have to really do a design review and [102:36] and and and all sorts of things with [102:38] those people first before you you get to [102:40] the right set up before you can actually [102:43] start actually writing code and and when [102:47] I was a survey ssin about the Lisa that [102:49] was very interesting when I first saw it [102:50] I first thought I think at the West [102:53] Coast computer Fair in San Francisco [102:55] Steve Jobs was there I don't know who [102:58] else from Apple what was their marketing [103:01] staff but I'd gone there with a friend [103:03] from Xerox and we looked at the star [103:05] system and we'd actually looked at the [103:08] fortune which was a system which was the [103:10] first 16-bit personal computer that was [103:13] available and they had a very fancy you [103:16] know this way and so forth and everybody [103:18] was looking at it and was beautifully [103:19] designed and everything everything else [103:21] that ran CPM or there and UNIX a version [103:23] of sort of here UNIX there was one test [103:27] in the software work that we had done as [103:30] for for real customers you know who [103:32] really wanted reliable software that [103:35] we'd accidentally come upon which was [103:36] called the keyboard mush you take your [103:38] hand and you run it across the keyboard [103:40] a few times and you see if your software [103:42] is still running [103:45] and I told this friend of mine from [103:47] Xerox about it so he wants over the [103:49] fortune system on the big podium up [103:50] there with a pretty girl sinning by it [103:52] and he tries it and the thing dies so we [103:57] kind of sneak away and we go over to the [103:59] Apple booth and there's Steve and the [104:02] other folks there and we decided we [104:04] weren't going to try it on and Lisa [104:06] so in reaching for a brochure though I [104:08] accidentally touched the upper right [104:10] portion of Lisa keyboard [104:12] they were networked at the time at the [104:14] show for demonstration and networking it [104:16] brought down that Lisa the guy helped me [104:20] try to reboot it it wouldn't come back [104:22] it also brought down all the other [104:24] machines at the booth on the network and [104:28] the only thing he finally could do was [104:30] to power cycle the whole system so I [104:33] just wanted to bring that out well now I [104:35] just want to bring out the looking for [104:43] the unforeseen okay right good point [104:45] just in the interest of time we're gonna [104:47] try it becoming shorter though yeah yes [104:59] the question is whether there's some [105:01] correspondence between the object [105:03] oriented programming metaphor and the [105:05] user interface metaphor and yes there is [105:07] in fact in the small talk user interface [105:10] which was one of the first of this type [105:13] and the small talk language which was [105:15] one of the first of the object-oriented [105:17] type the connection was very explicit [105:19] that you had objects that had generic [105:23] commands that could operate upon them [105:25] and that was something that existed both [105:27] in the language and in the user [105:29] interface so which was done even more so [105:32] in the star but we definitely the [105:35] programmers who were doing these user [105:37] interface definitely had that in mind as [105:38] a correspondence here John [105:46] oh yeah good user interface don't have [105:57] to I'm just saying it the user [105:58] interfaces that we were developing we [106:02] had that in mind but that doesn't mean [106:04] that a good user interface has to be [106:06] object-oriented no what did I use to [106:17] write the memos probably Apple writer [106:22] you let's see early on we were using [106:25] maybe Apple writer on the Apple - or [106:28] maybe UCSD Pascal probably using UCSD [106:31] Pascal program editor on an app used on [106:34] an apple - I didn't have I never had an [106:36] Apple three you're right you were [106:37] probably using either Apple writer on an [106:40] apple - or sophisticated people use the [106:42] UCSD Pascal editor and output it using [106:45] an inner off like program called Apple [106:47] script right we have put it to cue [106:49] printers when we could afford the time [106:53] and noise and to dot matrix printers [106:58] 80-column dot matrix printers and you [107:00] had a mix of those two before we got the [107:02] apple - an apple threes up jef raskin [107:05] had imbued us with polymorphic poly [107:08] eighty-eights using their editing system [107:11] and we did all of our editing on poly [107:13] eighty-eights Ciroc terminals back there [107:39] well I don't know about successfully [107:41] competing that part but yeah definitely [107:42] it was it was a extremely close to the [107:47] Mac user interface the gem user [107:49] interface by digital research and Apple [107:53] sent some kind of complaint letter and [107:55] there were some discussions between the [107:57] companies but then Microsoft and [108:01] hewlett-packard started doing Windows a [108:03] new wave and that was a much bigger [108:05] issue so Apple kind of stopped bothering [108:08] Digital research and instead got [108:10] involved in a big lawsuit with HP and [108:12] Microsoft Digital research at the time [108:14] was kind of a struggling company and [108:16] Apple didn't want to you know basically [108:19] pick on our little company so today we [108:21] picked any two companies that were too [108:23] big instead of picking on one that was [108:25] too little Bernard [108:41] yeah the the like the Xerox star and the [108:46] Lisa were the idea was that in both [108:50] groups was that people would only use a [108:52] few applications it's kind of true most [108:54] people only do use a few applications [108:56] but the the conclusion that therefore it [108:59] wasn't necessary to have third-party [109:00] applications was kind of ridiculous [109:02] actually in the Lisa it turned out we [109:04] did have a place for third-party [109:05] applications we thought for certain [109:08] vertical markets there would be [109:10] third-party applications and we'd have [109:11] accounting software and so on but even [109:14] then we were thinking very small scale [109:15] like there would be one page layout [109:17] application and there would be one [109:18] accounting application and and you know [109:21] a couple of vertical market things if we [109:23] ever had 20 applications or 30 that [109:25] would have been a very large number very [109:28] different from the Mac which were in the [109:29] very beginning was gonna try to do the [109:31] same thing as the Apple 2 and what the [109:33] IBM PC did which was go for lots of [109:35] third-party applications I think one [109:37] reason the Lisa was designed as it was [109:39] was to try to justify why there was this [109:41] project going on the company we already [109:43] had an apple - in an Apple 3 why do we [109:45] need this other thing and well the up [109:47] between the Apple 3 you know gonna have [109:49] all this third-party software but the [109:50] Lisa won't it was kind of a [109:52] differentiator it was a kind of a closed [109:54] system that was supposed to be [109:54] supposedly a plus turned out to be a [109:56] major - of course yeah well it's that [109:59] was not necessarily unique to Apple at [110:01] that point remember one of the leading [110:03] software companies of 1979 1980 was [110:07] personal software which became visit [110:08] Corp and their flagship product line at [110:11] that point was a failed product line [110:13] called busy on which was an attempt to [110:16] expand visicalc [110:17] into a comprehensive suite of [110:19] interacting applications a word [110:21] processor a database word star at that [110:25] point was also trying to expand and [110:27] everybody was trying to do what [110:29] Microsoft has successfully done with [110:31] Microsoft Office which is turn the thin [110:35] end of the wedge of getting one [110:36] successful application which Microsoft [110:38] had with Excel on the Macintosh and [110:40] turned that into a major suite that [110:43] delivers all of the application [110:45] computing needs of a given set of users [110:47] Microsoft has done it successfully and [110:50] one could argue that the default [110:52] computing platform right now is Windows [110:54] with Microsoft Office and not very much [110:57] else so I don't think that that [110:59] necessarily was a bad idea it may have [111:02] been many years ahead of its time but [111:04] Microsoft was selling the Microsoft [111:06] Office for Macintosh in 1985 I still [111:10] have box on my shelf where they supplied [111:11] the the word processor the spreadsheet [111:13] the filing program in the terminal [111:15] program in one box for one price for the [111:17] Macintosh so office suites are certainly [111:20] they certainly were not a dumb idea of [111:23] 1981 that's something that has really [111:26] monopolized the industry I think that [111:28] part's true thee sis on the ELISA what [111:32] was really one of the first Suites [111:35] and in addition to the ones that [111:37] personal software did and it was also [111:41] one of them it was the first probably [111:42] multitasking personal computer and but [111:46] basically ahead of its time and missing [111:49] the main point which was you needed a [111:50] low-cost platform that had reasonable [111:52] performance and that had lots of [111:54] third-party applications back there in [111:58] the aisle [112:24] the point is that we were testing in the [112:27] early years for totally naive users and [112:30] that over the years culturation has [112:33] taken place as I talked about the more [112:35] people approach computers with with less [112:39] fear and with more pre knowledge of what [112:40] they're doing is that your general point [112:48] yeah and the process came from a decade [112:50] of more of experimentation well I'll [112:52] tell you about an interesting user [112:53] experiment that I did in 1982 I took a [113:01] early prototype of the Macintosh and it [113:04] was then in a Plexiglas case just cut [113:08] panels of Plexiglas filed in glued [113:11] square we didn't have any of the [113:13] injection molded cases yet with the guts [113:15] inside it was running an early version [113:19] of mac paint which it which was called [113:22] max sketch at that point and it was [113:24] turnkey application you put the disc in [113:27] and booted it up and it went straight to [113:28] that application because there was no [113:30] finder at that point which was actually [113:32] the paradigm of most other machines [113:34] which was turned kyboot we put the [113:35] floppy in and you booted it and you got [113:36] into that one application and I took it [113:40] over to my girlfriend's parents house [113:42] for Thanksgiving where she had a [113:46] three-year-old nephew three year old [113:51] nephew and this was in 1981 video games [113:54] were even that hadn't even gotten down [113:57] to three year olds by 1981 that boy [114:00] spent four hours drawing with Mac's [114:03] sketch he learned it in no more than [114:06] fifteen or twenty seconds just you know [114:09] he pressed the button and draw things on [114:11] the screen and he was drawing things [114:13] with with an early version of Mac Paint [114:16] with virtually no tutoring and almost no [114:18] language at all with no color with no [114:22] acculturation at all so there were some [114:24] things that we got basically right about [114:26] human human factors if you can appeal to [114:29] a three-year-old and get a [114:30] three-year-old with no language skills [114:31] to [114:32] and how to do something productive in no [114:34] time at all that's not a cultural [114:36] statement you've done something right in [114:38] design and that's when I knew we were [114:40] really onto something I don't think it's [114:45] had no effect I think what acculturation [114:47] has done is it's it's gut it's made us [114:51] soft we don't address complexity anymore [114:53] the way we we sweated over complexity in [114:56] 1981 we were deathly afraid of [114:58] complexity we take it for granted now [115:00] you'll look at fries it's scary the kind [115:02] of things we get away with I think it [115:05] has made something's hard to change when [115:07] Microsoft announced they were gonna go [115:08] to single clicks instead of double [115:09] clicks on the desktop some journalists [115:11] said see they're leaving Apple in the [115:13] dust you know you're still in two clicks [115:15] and you're moving to one I said our [115:16] users on this doing this for 12 years [115:19] there's no way they're gonna change [115:20] we're never going to change it and maybe [115:22] the Microsoft users who've only been [115:23] doing this for a couple years can change [115:25] but as it turned out even a couple of [115:27] years using Windows 95 was too much and [115:30] and Microsoft had to back off on making [115:33] users to use single clicks in Windows 97 [115:36] because even two years was too much [115:37] people don't change we are out of time [115:39] now but there are some people here who [115:43] were involved in Lisa user-interface [115:44] work all the way from the Apple to the [115:46] Lisa and the Mac now maybe they could [115:48] stand up and a net Wagner especially who [115:52] was worked on the original Lisa look and [115:55] graphics and fonts and everything and [115:57] joy and Bob I mean once you all stand up [116:00] all you Apple user interface people I [116:03] think some of the users out here might [116:04] appreciate you pop glass [116:07] [Applause] [116:16] we're in a warehouse just down the [116:18] street to the right and Larry and Chris [116:20] would you walk through there to answer [116:21] questions right [116:23] [Applause] [116:26] [Music]