What's the rationale behind Google's "no save" approach?

Question

Before anything, this is something I'm seeing on several sites, not only Google, but I think it started with Google, and it's obviously the most known case. There are several UX aspects quite arguable in Google docs, but I think this is the one that stands out the most: when you edit a document, it's automatically saved, the Save option doesn't even exist.

While I can imagine some reasons, the lack of affordance is really disturbing. As an example, many clients tell me by mail that they have edited the document because they have no idea what happened, if it's saved and/if I'll see the changes they made.

So, does anyone knows why is this? is there any publicly available document explaining the rationale behind this approach?

Answer 1

Save is a byproduct

Save is a byproduct of early hardware- and software design. It doesn't have a common equivalent in the real world.

Consider: If you take a pencil and make a mark on paper, that mark doesn't require an extra step in order to become permanent.

In other words, it does not need to be saved. The paper may need to be stored somewhere so it can later be found, or copied so it can be shared, but those are different tasks than putting permanent marks on the paper.

Old-fashioned Save became about more than saving. It was combined with tasks such as these:

• Decide where to put the file.
• Name the file, so it can be recognized.
• Choose the file format, with an eye to sharing it.
• Choose to make copies, by using Save as, perhaps as backups.
• Choose the file format, with an eye to faster hardware performance.
• Change the file format, with an eye to forcing the software to reformat the file to "fix" a defect in the file.
• More...?

The no-save approach reflects what happens in the real world—the pencil mark is permanent without an additional step. And the no-save approach requires no learning, except unlearning to Save.

• My stuff ends up in default locations.
• My stuff can be moved into folders (that I choose to create) as an explicit task.
• My stuff can be renamed as a separate task.
• My stuff can be shared automatically, or shared manually as an explicit task.
• My stuff can be shared, read, and modified by others at the same time, removing the need for copies.
• My stuff can be converted or exported as an explicit task.
• My stuff tracks changes by itself, so I can roll back to an earlier version.
• More...?

Google and others have taken the brave step of challenging the paradigm. Having users click Save when they really want to back up, share, export, move, or identify stuff requires the user to adapt to the software and puts the focus on the software rather than on the user's goal or the user's content.

Which came first: the technology or the product strategy?

Technology made SaaS and "data in the cloud" possible. But the accompanying no-save shift didn't happen because of an engineering decision. Instead, the engineering decision happened because of the product-management strategy—to gain market share by providing people with software and (their own) content everywhere they want it. This convenience is called "production of time and place" and it has tremendous potential value. Similarly, enabling multiple users to remotely edit the same document (as noted by @Rayraegah's reply) is another form of "production of time and place".

Aside. Production of time and place is a concept from business management. It's most easily explained like this: a supermarket sells an item for $1—until they close at 6:00 PM. An all-night corner store sells the same item for $2—even at 2:00 AM. Sometimes you're willing to pay more for the time and location for the same item because you're also getting convenience. The corner store has produced "time and place" for you.

Always-On software and data is the product vision. The no-save paradigm—a technical solution—had to follow in order to solve the connection-interruption problem, those in-between moments when Always-On is temporarily off.

What do you think?

Answer 2

As answered by JeromeR the Save paradigm is a byproduct of early hardware software design. For simplicity I am only going to talk about two types of memory. "Save" actually means moving information from temporary memory (RAM) to permanent memory (Hard disk, flash ROM, etc). Temporary memory (RAM) can only keep information while it is powered on. Permanent memory can keep information even when powered off. Additionally, temporary memory is where the computer does all its processing. So when you are working on a document everything is kept on temporary memory (RAM). In most computers if you don't Save your work you will loose it as soon as you power the computer off.

This paradigm started to change with PDAs and cell phones. Some of the early adopters of the No Save paradigm was Palm (remember the Palm Pilot?). This device used to Save your work as soon as you switched to another application. So there was no explicit Save command (for the most part).

And now with the advent of SaaS (Software as a Service) where everything is in the cloud some companies started using the "Save as soon as possible" to avoid loosing user's data when the internet connection is lost. I saw initial inklings of this approach in Blogspot (now known as Blogger).

A similar paradigm is the Play/Pause/Stop functions in early MP3 music players. Nowadays is rare to have the Stop function but in early music players it was always present. In a computer based MP3 player playing a song meant opening an MP3 file and start reading from the beginning of the file. When you selected the Stop function it meant closing the file and forgetting where the song left off. So if you selected the Play function again it would start from the beginning. The only way to continue from where it had left off was to select the Pause function and then the Play function. This was different from a tape player but similar to a vinyl record player. But it did not matter. The underlying reason was the opening and closing of files. If you wanted the pause function you had to make an extra effort to keep note of where you left off when pausing the song.

The origins of the Play/Pause/Stop functions came from tape players. The Pause function in tape players was mainly used during recording to minimize the time between pressing the record button and the time it actually started recording; which used to be close to 1 second when not using the pause button. The pause button could also be used during playback but there was not much difference with the Play Stop combination except that using the pause button kept the device engaged and using energy which did't feel comfortable for most people so we only used Play/Stop. The same functionality was inherited on CD players for social inertia reasons (why change an understood interface?). Son when MP3 players came along on computers and their stand alone versions we just kept using the same ol' same ol' interface. But in solid state MP3 players it stopped making sense to have a Stop function. From the user's perspective you really need "Play music" "Don't play music" only. The first MP3 players where I saw this was a small Samsung player with the shape of an egg and shortly after on the iPod.

It is easier to see these thing in hindsight but much more difficult when nobody has thought of a better solution. And even more difficult to fight social inertia even when a better solution exists.

Answer 3

FYI, they used to have a save button in Google Docs: http://googleappsupdates.blogspot.com/2010/02/new-saving-buttons-in-google-docs-and.html however, it's been removed in Google Drive.

I can't find anything online stating why they removed it, so can only speculate. Given that Google is an engineering centric organization my guess is that the change came after engineering improvements. I imagine they managed to make the process of auto-save fast enough where it was no longer necessary to have a noticeable gap between auto-saves. It's now virtually instantaneous.

The other thing to note is that documents on Google Drive can be shared and editing live. For that to work--where multiple people are editing the document in real time--there has to be a nearly continuous auto-save syncing with the server to replicate to the changes to everyone. To be consistent with documents only you can see vs. ones you're sharing with multiple people, they may have decided to turn autosave on for everything.

Answer 4

It's an Engineering decision

That simplifies and complements some of the features Google docs boasts about

• Real-time Collaboration
• Offline editing
• Revision history
• Cloud storage

...allowing the user to focus only about writing/editing the content while the technology ensures that their precious content is always preserved.

Content you edit on the document is streamed into the server and to other collaborators (at real-time). A save button here is meaningless as every keystroke is recorded on the go from every collaborator.

The same principles applies when you go offline, except the content is streamed into a local cache and uploaded into the cloud storage when the devices is online again. If you've had collaborators edit the document in the meantime, then their versioning systems lets you easily resolve any conflicts.

From Wikipedia,

Autosave is a function in many computer applications or programs which saves an opened document automatically, helping to reduce the risk or impact of data loss in case of a crash or freeze. Autosaving is typically done either in predetermined intervals or before a complex editing task is begun.

I wouldn't use the term autosave to describe what google docs does, fundamentally it's the same as autosave but under the hood its the successor of autosave where data is saved or accurately put - "streamed" into the storage area for every keystroke and interaction. It even goes the extra mile to mark where yours and the collaborators cursors are and what you've/they've highlighted. Think of it as watching a screen (but include privacy) when you/they edit a document.

Simply put, you can still lose data with autosave, but with streaming: nothing's lost.

I can edit the answer to add the details on the engineering behind this if need be but @JeromeR's reply should be more than sufficient in explaining these concepts to a layman or non-tech person