It’s a concept that companies have dabbled with over the years. Jef Raskin’s original concept for the Mac, the Xerox Star system and (to a lesser extent) the Lisa system all tried to hide the concept of “app” from the user. You would open and work with documents and the OS would dynamically start and stop whatever processes were needed to let you do your work.
iOS is, IMO, the first commercially successful operating system to implement this paradigm (or something close to it), but it’s not new. It is, however, completely different from the paradigm used by traditional desktop operating systems like Linux, macOS and Windows.
I’m wondering if you could amplify this just a bit, David. My understanding of the iOS paradigm is that it emphasizes apps over documents. When I tap an icon on iOS, I very clearly perceive I am launching or switching to an app. It was only recently that Apple implemented an app called “Files” that contained documents produced by apps. Otherwise—again, in my perception—the Maps or Music or Weather apps are presenting information directly rather than opening discrete documents that I can choose for interaction. Maps can save favorite locations or download sections for offline viewing; Music contains tracks; Weather, like Maps, can save favorite locations. But I don’t ever interact with any of those bits as discrete documents.
I can see where that all could be turned on its head and one could say “Well, you are really interacting with a highly programmed document.” Is that how you’re thinking of it? Or is it something else I’m missing here?
The systems I referenced (Lisa, the Canon Cat and the Xerox Star) were deliberately document-focused. That’s not the similarity I was referring to, but the fact that the processes providing the document-editing capability would be dynamically launched in an on-demand fashion and you could not explicitly quit them (or for that matter, even know when the OS quit them). They would be shut down when the OS decided they were no longer necessary and would be dynamically re-launched when they became necessary again.
On the iOS platform, there is similar behavior. You launch an app by tapping on it, but when you put in the background by pulling up the home screen or by switching to something else, it doesn’t necessarily quit. The app and its various “scenes” will change to different states, which may involve running in the background, being suspended, unloaded from memory or fully quit. You are never informed about these state changes, and when you switch back to it, the app re-launches or its scenes change state, again without you being aware of the changes.
This is completely different from a desktop OS like macOS, Windows or Linux, where you explicitly start and stop apps. They may go idle in the background and they may be “swapped” out of memory to make resources available for other apps, but they do not quit until you tell them to quit (or if system resources actually run out and the OS starts killing processes to avoid crashing).
EDIT: I took some time to read an Ars Technica article on Lisa and now I see what you’re saying: No “Quit” command, just “Set Aside” individual tasks or “Set Aside Everything.” The same article calls it “document-centric” in the sense that double-clicking one of the application icons would result in a message to go back and tear off a sheet of, for example, LisaWrite “paper”…I think that may be different from what you’re describing and the reason for my confusion.
Original post:
So (and pardon me if I seem a bit slow here), by “document-focused” you’re referring to the app remaining active as long as there was work for it to do, either actively or potentially. i.e. if the work the app was doing eventually went away, the OS would eventually kill the app until it was needed again.
Having used Lisa extensively, I wasn’t aware that it worked that way…especially with limited RAM and an under-5mHz processor driving a huge video display. I knew it could multi-task after a fashion, but when I quit LisaWrite to use LisaDraw, I presumed I was really quitting it.
I haven’t actually used Lisa, but based on what I read (which might be wrong), you would not typically launch an app. Instead, you would open and close documents (creating new ones by copying template files, similar to how Mac OS’s “stationary pad” Finder option works). When opening a document, it’s app would launch. And when closing the document it would (probably) quit.
I also remember reading that open documents were associated with storage devices. So you could eject a floppy with open documents and the documents would all save/close prior to the eject. They would auto-reopen when the media was re-inserted. So floppy disks could be used to contain complete editing sessions, storing the full state of the session, not just documents.
I think the Ars article you cited aligns with what I remember reading.
The only difference is that you were originally correct about “quitting”—it would not. The interface simply says “Set aside [this document]” or “Set aside everything” and the underlying code would still run in the foreground until you switched contexts. The article seems to imply that the OS would eventually swap the running code to the 5MB hard drive to free up space for whatever was in the foreground.
An implication of documents being associated with storage was that you couldn’t simply move an icon from one drive to another to install an application—you had to explicitly duplicate it, because you needed the “paper” associated with the app and it needed to be associated with its new home.
Sounds like OpenDoc has come back to life!
I am in the habit of properly closing iOS apps (by swiping them up and off the screen) but perhaps I need not bother?
What about Newton OS? You did close apps, but they weren’t really closed. Wasn’t there something about them still occupying space in the “soup”?
I can’t remember the details, but I do remember that I had a third-party tool on my MessagePad that could “freeze” an app, so that it was still installed but no longer used any resources (except for storage space).
That was the fascinating thing at the time about Newton. Data were not segregated into discrete containers, but in one large container popularly called a “data soup.” Apple patented a method for both tagging information with a time it would be needed and an “automatic query formulation” system for retrieving relevant information at that time. Instead of storing my calendar information in, say, a BusyCal data file and my contact information in a BusyContacts file, it’s all in one “file” with discrete tags, so apps like Now Up To Date and Now Contacts are running queries on the entire data soup.
It saves storage space (because the tags add incrementally to your storage needs and you’re not duplicating data in different containers) and searches run more quickly when they don’t have to keep opening files or segments of files to find stuff.
The tool on your MessagePad likely worked as you describe, since the single storage soup was always available.
In a limited storage/limited processing/limited energy device like Newton, that was a breakthrough concept. I don’t know how that would translate to iOS and other current Apple systems.
I don’t quite understand what Google means by that, unless they’re saying that an app’s code was removed from the working area and then tagged and pushed into the soup. Unlike, say, an iPhone, our MPs had limited facilities for swapping data or code in or out of the device, so it all had to go somewhere. Calling it “recovered space” would be misleading in that sense.
I had Newt Tools as well, and the little I recall about it was that using it would allow installing more apps than would otherwise be possible.
Maybe the way to think about it is that a tool like that would operate on code but not data, because the data soup was available to all apps.
This hearkens all the way back to Jef Raskin’s original concepts for the Mac (later productized in the Canon Cat).
His theory is that a user-visible file system is unnecessary if you have a sufficiently-powerful search mechanism. I see quite a bit of that in many of Apple’s apps (e.g. iTunes, Photos and Books).
Google also uses this model, at least in GMail. In GMail, there are no mail folders - all your messages are stored in one huge blob of mail messages. You can apply tags to messages, and the web UI lets you filter the blob based on those tags. Even the trash and your Inbox are just two more tags. And you can construct searches, either over the entire blob or in conjunction with the tags. And when you use a folder-oriented interface (e.g. IMAP) to access it, the “folders” you see are all “smart folders” - predefined searches designed to filter the blob on the tags.
It’s a great concept. It seemed completely nuts in the early 80’s, when Raskin first started writing about it, because physical storage limits (floppy disks and hard drives too expensive for normal people to own) made it pointless. But today, when even cheap devices have really fast multi-GB storage devices, and processors are fast enough to maintain and search huge indices, it makes a whole lot of sense.
Combining Newton’s soup and the thread about early internet access, who else used MacSoup? A combined newsreader (especially for offline use) and a simple mail client. Once you’d set up favourite newsgroups (comp.sys.mac.portables and comp.sys. mac.comm along with alt.marathon) and your e-mail accounts, one connected with cmd-K and everything new was downloaded. That way I was set for reading between patients on my PB2400c for the day. For some reason that PB was not sold in Canada, but I got one through Small Dog Electronics.
Reminds me of a secretary in my Dad’s office long ago, who instead of creating separate documents, would just add pages to one document. Like, one giant Word Perfect file is all she had. She just printed selected pages.