Last Mini Store

ifo Apple Store reports Apple is closing it’s last Mini Store.

The Oakridge store—and five others—opened October 16, 2004, and all occupied a similar size—587 square-feet in the case of Oakridge, or about one-fifth as big as full-size stores of the time. The mini-stores were born of one goal and one realization. First, Apple wanted to extend the span of their retail initiative into more new territories, increasing the percentage of Americans who were within 15 minutes of an Apple store. Just as important, then-Sr. VP Ron Johnson said the company analyzed revenue and store sizes, and learned that smaller stores generated nearly the same revenue of larger stores, but with less construction, lease and and maintenance costs.

I was a Mac Genius when the first Mini Store opened in 2004. At 30 feet wide (the typical Apple Store was 45 feet wide), I already thought my store was cramped. I can’t imagine working in a closet store for over ten years.

At the time tipsters said there were plans for more mini-stores, including at alternative locations like airports and universities. However, no additional mini-stores ever opened beyond the original nine. By November 2008 the first of the mini-stores (Bridgewater, NJ) was converted to full-size. It’s taken over six more years to move the remaining minis into full-size spaces because of a scarcity of appropriate mall spaces.

It would have been fun to see more Apple Stores in more out-of-the-way places, but as Apple’s popularity exploded the limited capacity of the mini Store was no longer a viable option.


Clark Goble reminds us that we are all looking through rose colored glasses when we compare the reliability of Mac OS X 10.6.8 Snow Leopard to OS X 10.10.2 Yosemite.

The reason people have such fond memories of Snow Leopard is because they are colored by the end of its life and not its beginnings. But it’s hardly fair to compare 10.6.8 to 10.10.0 or even 10.10.2 (that just came out last week). I do think it’s a fair criticism that upgrades started coming faster with Lion. Snow Leopard came out August 28, 2009. Lion came out July 20, 2011 nearly two years later. However Mountain Lion came out July 25, 2012, only a year later. It’s been around a year for each release since. That is we no longer have the stability of a year with a solid mature OS with most of the major bugs fixed.

Clark includes a long lists of bugs found in early versions of Snow Leopard to back up his claim.

Remember, no one is forcing you to upgrade to the latest version of OS X. If you want a more reliable operating system now, stick with Mavericks, and upgrade to Yosemite next year after all of the bugs are worked out.

Genius Bar Logos

ifo Apple Store relays the sad news that Apple’s is removing the historic Genius Bar logos from its retail stores.

An original and significant element of Apple’s retail stores is disappearing. Over the past month workers have been removing the “atom” symbol that has pinpointed the Genius Bars since the first store opened in 2001, and they are replacing it with wall graphics to match those recently installed in back-lit wall displays. The Corte Madera (N. Calif.) store was the latest to make the change. The symbol was based on the chemistry depiction of an atom, meant to signify “genius.”

I worked under the historic Genius Bar logo for over three years. I always though it was classy and elegant, even if the title of “Genius” was a little much. I will be sad to see it go.

Missing the Zip

Christopher Phin remembers the Zip Disk.

A little over 20 years ago, however, when Iomega introduced the original 100MB Zip disk, that was staggeringly huge for a removable disk. The wildly more common 3.5-inch floppies held 1.4MB. For context, the entry-level PowerBook 150, introduced in the same year, had a 120MB hard disk, and the base configurations of even 1994’s server Macs came with hard disks that were only five times the capacity of the Zip disk.

The Zip disk was popular because it was small and cheap.
In the late 90’s it was the Air Jordan’s of the Sneakernet. But by the mid 2000’s, USB flash drives were smaller, CD-Rs were even cheaper, and both could store more data.

I made sure to purchase a 250 MB Zip drive with my Power Mac G4 in the summer of 2001. The Zip Disk was the standard mechanism of file transfer in the design industry, and I did not want to be left behind. I can’t remember using that Zip drive very much. By the time I was out of art school the whole industry had moved over to USB flash drives and rewritable CDs.

FileVault Deferred Enablement

Rick Trouton documents some of the powerful new FileVault features in OS X Yosemite.

Apple recognized that there would be situations where Mac admins would need to set up FileVault 2 for a person where the admin would not have the password for that person’s user account. To avoid the immediate need to enter a password, fdesetup has a -defer flag in Mountain Lion, Mavericks and Yosemite that can be used with fdesetup‘s enable verb to delay enabling FileVault 2 until after the current (or next) user logs out. With the -defer flag, the user will be prompted for their password at their next logout or restart. The recovery key information is not generated until the user password is obtained, so the -defer option requires a file location where this information will be written to as a plist file.

The new commands allow system administrators to enforce FileVault 2 at login and logout with the use of both institutional and personal recovery keys.

Powerful Newton APIs

Brant Sears, Newton developer, on the Newton’s powerful APIs.

I was a Newton programmer for a few years writing medical records software. The persistent storage solution on the newton was really wonderful. I remember working with it very fondly. It was my first real job as a professional programmer. Our company made versions of our software for Newton and Windows CE. We only had one Newton engineer (me) and many Windows engineers. I was always able to keep the newton product ahead of CE despite working alone because of the tremendously powerful APIs of the Newton. Even a year after cancelation our Newton software was far outselling the Windows version. I am a professional software developer today because I truly fell in love with the Newton and I like to think that a little bit of the design philosophy of the Newton rubbed off on me.

The Newton was never marketshare leader in units sold, or the number of developers required to support the platform.

Newton Storage

Anyone who has used a Newton to enter data, and then returned to that data months or years later, knows how rebust the storage system is.
But it wasn’t always this way. Landon Dyer, Newton developer, on why the Newton needed a strong storage system.

One afternoon Michael Culbert, the Newton Technologist, came into my office to discuss battery contact bounce. I’d been nervous about the robustness of the storage system and had talked with him about it before, and now he confirmed my worst fears. Battery contact bounce is the jiggling of the power connectors when you toss a device onto a hard surface; the device can easily momentarily lose power and reset, and if the Newton was in the middle of a storage update all the data would be lost.

In order to fight battery contact bounce, and other forms of data corruption, Landon came up with a transaction-based storage system for the Newton. Here’s how it worked:

Imagine that you have a notepad entry, with a bunch of text. The NewtonScript storage layer breaks up the notes into a bunch of small objects, including the text itself, plus some extra objects for searching. There are objects containing structures that allow the text to be quickly searched, and so on.

Now say your original note was, “Buy milk,” and that you add “Bread, too!” to it. What the Newton does is create a whole set of shadow objects, just like the old ones but with your changes applied. Then, with a single write to a single byte somewhere in the store the storage system commits your changes, then goes back and deletes the outdated objects.

If the power fails before the commit point, the Newton just deletes the new objects and you haven’t lost much work (you just have to remember to buy bread). If the power fails after the commit point, the Newton just ensures that all of the old objects have been gotten rid of (so it can re-use the space they take up).

This sounds simple in principle, but in fact it’s quite difficult to get correct. Additionally, the flash storage we were using had the amusing characteristic that bits could go bad, which is a little like having to design a car with an engine that might lose a gear or two and still have to maintain freeway speeds without the driver even noticing.

Due to Landon’s efforts I can’t say my Newton has ever lost data, or thrown a gear while driving at highway speeds.

Today, even with the benefits of desktop sync and cloud backup, we still take the integrity of our devices’ data for granted. The Newton, although often remembered as a failure, did bring the reliability of handwritten notes to our digital world. As for the original PalmPilot, well you just had to hope there was a up-to-date HotSync before your batteries ran out.

Newton Vs. All

Speaking of Graffiti, Phil Gyford attempts to answer the age old question, which is mightier the stylus, the pen, or virtual keyboard?

For some time I’ve been meaning to test my small collection of PDA/smartphone gadgets to see which of their methods of input was quickest. The iPhone’s software keyboard? The Newton’s handwriting recognition? Palm’s Graffiti?

Here is what Phil had to say about the Newton.

This method was easier than I expected and it felt like it was as quick as handwriting recognition could be — there is some delay in translating my scribble into text, but it’s no slower than the speed of my writing, so the device didn’t get behind. Once I got into it, correcting mistakes was also easy: tapping a word brings up alternative spellings and capitalisation, and one further tap away are two ways to manually correct the characters.

Here is what Phil has to say about the Palm.

In theory this simpler method is less error-prone than having to interpret normal handwriting, although I remember that even when I was using the Vx every day I found it at least as frustrating. Small mistakes mean letters are mis-interpreted and, then and now, I was forever having my ‘Y’s appear as ‘X’s.

The results are not far off from what I expected. I still feel he could have done better with the Newton, and the Palm given more practice. Read the full account to find out which handwriting recognition method came in first.

Five Things Wrong

Landon Dyer, Newton developer, gives us five reasons why the Newton failed compared to the Palm Pilot.

Ultimately the Newton was a market failure. If you look at the competition at the time we did maybe five things wrong that the other guys got right or chose not to try to address:

One. Price point. The Newton was about a thousand dollars. Ouch. The Palm Pilot was about $300.

The Newton’s technical advantages worked against it when competing against the Palm, that had many of the same features but sold for a third of the price.

Two. Form factor. The Newton was large and weighed about a pound. The other guy fit in a shirt pocket.

Before creating the Palm Pilot, Jeff Hawkins whittled down a piece of wood and carried it around in his shirt pocket in order to approximate the size and weight of his future digital assistant. While the Newton’s technical advantages gave it unnecessary bulk compared to its competitors. The Palm Pilot was just more portable in a time when mobility over specs mattered.

Three. Handwriting recognition wasn’t quite there (and the production Newton had a digitizer noise issue that we found out about only later that Fall, which dramatically reduced the recognition rate). The Pilot used a much more primitive letter-by-letter system, but people got it and it worked well after a little training.

The beauty of Graffiti, the Palm’s letter recognition system, “is that is doesn’t work like handwriting recognition. It actually works like a keyboard.” It is easier to get people to write in a way a computer can read, than get a computer to read the way people write. The Palm Pilot made the most of limited technology. Although the Newton’s handwriting recognition got better, it was always trying to decipher bad handwriting, something even us humans have a hard time reading.
No wonder it got a bad rap.

Four. No real apps … and you had to pay Apple a commission. For a totally new platform, charging your developers to develop software is an uphill battle. (Of course, all this changed with the iPhone, but the demand was very high). The commission idea was just another stupid and reality-disconnected idea from upper management; instead of attracting developers (who already had to pony up over a thousand bucks for a dev kit) I think it discouraged folks from even considering developing for the Newton.

Combine that with the fact that most software was distributed via expensive PCMCIA card, and syncing software between the computer and Newton was complicated.
Without a viable software distribution model, and a flourishing development community, the Newton didn’t stand a chance.

Developing on the Pilot was a lot like programming a 68000-based Mac, and pretty familiar to many programmers, while NewtonScript was something from another world (even if it did have many cool aspects).

Five. The “MessagePad” wasn’t all that good at actually messaging anything. It was awkward to connect a Newton to anything (via a cable or PCMCIA card), and the modes of communication were either inconvenient or expensive (wireless pay-by-the-kilobyte). The Newton was about 15 years ahead of the technology curve here.

One of the miracles of the Palm Pilot was the reliability and ease of use of the out-of-box HotSync. The Newton came with a lot of features advertised on its box, faxing, beaming, emailing, and placing phone calls, but often those tasks were obstructed by the purchase of additional hardware and the required complication of the day.

What might have hurt the Newton most of all was the “magic date” for which it was released.

The Newton probably needed another three months or so of bake time before we shipped it. By November or so we’d patched nearly all of the software issues that critics (rightly) complained about, and I like to think that the reception would have been much kinder if we’d worked just a little longer.

John Sculley insisted on a strict ship date for the Newton, because he saw the project falling behind. Ship dates are important. They help constrain feature creep. But releasing the Newton before it was ready, gave the Newton a poor reputation. The rest is Egg Freckles.

Product Wide View

Landon Dyer, Newton developer, looking back at some of the Newont’s design decisions in contrast with the Palm Pilot.

Yeah. I bent heaven and earth and did some of the longest hours in my career making the Newton’s storage system bulletproof from crashes and other failures, while Palm’s solution was to make it really easy for the Pilot to talk to a PC (whereupon you got backups of that data we were trying to protect AND you got a communications story that didn’t utterly suck).

That was a valuable lesson: Even coders at the coal face of your product need to have a product-wide view.

It is ironic that the Newton MessagePad “wasn’t all that good at actually messaging anything. It was awkward to connect a Newton to anything (via a cable or PCMCIA card), and the modes of communication were either inconvenient or expensive (wireless pay-by-the-kilobyte). The Newton was about 15 years ahead of the technology curve here.”

Simple desktop sync is just one area where the original Palm Pilot got it right.