What the Apple Newton taught us about UX 27 years ago
By: Jesse Freeman
Tags: User Experience, Design, Education, Technology, Startup

Application View

The proto view was the building block of the Newton’s base application. The Newton used a series of screens to display an application’s UI, just like we see today on mobile phones and tablets. The default view would have a title at the top and nav bar at the bottom.

In this example, there is a small pop up clock button on the left and a close button on the right. Since the Newton had a dedicated navigation area at the bottom of the screen, most navigation UI was towards the bottom of the application’s view.

Headers

You can add a header to the application. This usually consists of an icon on the left, some text, and a horizontal line that goes across the rest of the screen.

This helped display the title, a custom title, and could even have additional icon buttons for contextual actions.

For all of the forward-thinking that went into the Newton’s UI, there were no rules around how an application could look or feel. So most developers implemented custom looking layouts, which meant that things we now take for granted like a consistent location for the time, date, and notifications did not exist.

Folder Tab

Applications could also make use of a folder tab that went along the top of the view.

While this is commonplace now thanks to web browsers, back in the early ’90s, this was a new concept. The newton actually implemented this as a drop-down menu instead of the way we know of tabs today. To make use of the space, developers could also include the clock, which wasn’t a fixed UI element along the top of the screen like we have today.

In addition to the folder tab, developers had access to sub-tabs for jumping between data views in an application. Here is an AZ tab navigation example typical on the Newton.

Since the Newton was limited in how many pixels it could display on the screen with its 320 x 240 pixel resolution, designers had to cram in as much as they could. Here you can see that the tabs automatically increment two letters at a time since it wouldn’t be possible to display 26 individual tabs at a time. Some letters actually touch the border of the tab because there simply isn’t enough space to have consistent padding.

This wouldn’t acceptable with today’s UI design. Most likely, tabs would be missing to allow for scrolling left and right, so each letter would have the same spacing and padding.

Manu Bar

As we saw earlier with the default application view window, the bottom of the screen was reserved for an application menu bar.

There was always an information button on the left to display help pop-ups for users. Next was usually the font and keyboard input options. Then it was up to the developer what they wanted to display. Since there was no drop-down menu like you would have on a desktop computer, most actions were buttons in this menu bar.

When there wasn’t enough room to display all of the actions in the static menu bar, developers used a floating bar with additional options.

Finally, all applications needed a way of closing, so the exit button was always the last opinion along the far left of the menu bar. A lot of thought had to go into minimizing the actions of an application depending on what kind of buttons you used in the menu bar and how much space was available.

Buttons

Buttons are the building block of any UI, so it’s not surprising that the Newton supported several types of buttons from simple text to borderless icons.

One thing that was rare on the Newton was compound buttons that combined an icon and text. This was probably due to the limited space on the screen, especially when it came to action buttons in menus.

Input Fields

I could write an entire article on the Newton’s text input components. The most basic one was just a simple input field with a label no the left and a dotted line indicating it could be edited.

Because of the Newton’s unique handwriting recognition, there were some additional options that became available when access text input fields allowing you to toggle between script or the virtual keyboard.

Radio Buttons

The Newton had radio buttons developers could also include in their user choice options.

These radio buttons were minimalistic, using a dotted outline for an unselected option and filled circle for the current selection. Today, the dotted line circles would read as disable or not selectable, and I wonder why they didn’t go with standard circle outlines? Perhaps with all of the other think outlines, it would have been too difficult to stand out on a crowded screen.

Checkboxes followed a similar design with dotted rectangle outlines for unselected options and a small checkmark on top for selected.

Pickers

Pickers are usually a combination of a button and some kind of scrolling list. The Newton had support for pickers as well, and these often took on the appearance of what we would consider contextual pop-up menus that appear when right-clicking on today’s computers.

These pickers were always triggered by a button and could contain icons, text, checkboxes, and even horizontal dividers.

Based on the location on the screen, the picker would appear below, next to, or above the button.

The Mac was well known for its use of icons throughout the OS, so the Newton leaned heavily on clear iconography wherever possible. I like this example of a person, company, and group used in conjunction with the text to add more personality to the picker.

Finally, additional UI elements could be combined with pickers to create more complex interactions. In this example, there is a title, a list of text, sorting tabs on the right, scrollers below, and a close button.

Today this would be too much UI for a single picker, especially since the close button is redundant. Now we expect to close a pop-up picker by clicking outside of it or making a selection.

Modals

Modal and pop-up views were a big part of the Newton’s UI. These could be simple display screens telling you about the current application or show some kind of help message.

Modals could also promo the user for action or modify settings.

While a modal could contain most of the standard UI components, a typical application was only able to display one at a time.

Finally, the border, title, and close options were consistent across the OS.

Scrollers

It wasn’t particle to expect the developer to be able to display all of the content a user needed on a single screen at a time. So the Newton had a scroller that could be tied to lists for paging up and down.

Scrollers typically sit to the right of the UI component they control. Unlike desktops operating systems, these scrollers didn’t extend to the hight if the viewport.

While this may have been efficient in small lists, using these scrollers for lists taking up the entire screen was not ideal.

There was no “smooth scrolling” on the Newton. Lists refreshed slowly, line by line when you scrolled up or down, making this a chore in most applications.

Sliders and Progress Bars

Visually, sliders and progress bars were identical. The only difference being the handle on the slider.

One downside of the slider, and most of the Newton’s UI, was the size of interactive elements. In the case of the slider’s handle, it was difficult to click on even with the stylist. Components requiring dragging tend to be a bit frustrating to use, especially with the Newton’s slow redraw rate.

For progress bars, used in the battery gauge example, the slider’s handle was removed and managed programmatically.

Dividers, Titles, and Status Bars

While I touched a bit on some of the standard title bars an application could display across the top of the screen, there some additional UI components a developer had access to for breaking up the visual flow of a screen. Even back then Apple knew the importance of grouping UI together in order to create a readable visual hierarchy. All of these elements shared a similar design aesthetic stating with the divider.

The Newton UI used a lot of heavy horizontal lines to separate elements on the screen. The divider was unique in that it allows text to in the middle of it, unlike the traditional horizontal rule we use in web design.

The same design aesthetic applied to the status bar, which we saw in the beginning.

Unlike the divider which breaks around the text, the status bar’s icons sit on top of the line. This was a strange design choice and made these status bars feel a bit cluttered when a lot of options or icon buttons were in them.

Finally, there was an individual title that supported a small icon, text, and a line below the two.

I wasn’t able to tell if you had any control over changing the thickness of these divider lines. It appears that each component had a set line thickness, and it was up to the developer to place them according to what works best for the visual weight on the screen.

Fonts

The Newton had an impressive collection of built-in fonts. Users were even able to adjust the size of the fonts as well. In total, the Newton had around 12 or so fonts that were common on the Mac OS of the time.

Also, developers had access to similar font display options you’d expect today.

While some of these fonts were better than others, text elements in the core UI components all shared a similar font and set size based on the default design of the component. As far as I know, these could not be changed, and there was no way to increase the system font size for people without 20/20 eyesight. Overall, the UI fonts on the Newton were tiny to display as much information as possible on a single screen.

Everything Else

There were a lot of additional UI components I didn’t go into detail above but wanted to call out quickly.

There were different types of expandable and collapsible rolled lists as they called them:

Outside of accordion lists, there were scrollable images that were masked off inside of a viewport:

For tabular data and help with laying out content in a view, developers had access to tables:

And finally, there were several ways to visualize the date and time from simple calendars:

Along with analog and digital clocks:

You can start to see the early shift toward skeuomorphic design in their UI. The digital clock example is reminiscent of an old alarm clock radio that used number cards attached to a wheel to display the time. You can see this reference in the dotted line across the middle of the digits.