7 Explained the production of time and place.
source | link

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 editingedit 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-On is temporarily off.

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, multiple users remotely editing the same document is another form of "production of time and place".

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.

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.

6 added 75 characters in body
source | link

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.

A pencil mark doesn't need to be made 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, and soworld—the pencil mark is permanent without an additional step. And the no-save approach requires no learning—exceptlearning, 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, multiple users remotely editing the same document is another form of "production of time and place".

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?

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.

A pencil mark doesn't need to be made 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, and so 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.

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?

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.

A pencil mark doesn't need to be made 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, multiple users remotely editing the same document is another form of "production of time and place".

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?

5 edited body
source | link

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.

A pencil mark doesn't need to be made 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.
  • ChooseChange 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, and so 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.

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?

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.

A pencil mark doesn't need to be made 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.
  • Choose 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, and so requires no learning—except unlearning to Save.

  • My stuff ends up in default locations.
  • 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.

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?

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.

A pencil mark doesn't need to be made 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, and so 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.

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?

4 typo
source | link
3 Added the editorial comment at the end.
source | link
2 deleted 3 characters in body
source | link
1
source | link