I loved Cyberdog - I had one window that contained something like bookmarks for 'everything internet' (usenet newsgroups, email, web sites, ftp sites). It was in list mode, and my recollection is that you could just click the disclosure triangles to see, for example, what was in the email inbox, or whether there were new posts in rec.games.roguelike.
I also owned WAV (an OpenDoc word processor). I was way too far ahead of the curve.
That sounds right to me. If one spent a lot of time using the internet apps it was an all in one application with a single memory footprint. There was even gopher.
One thing the article doesn't talk about is RAM prices in 1997. The computer used by the author has 56 MB. But before the great RAM price crash, most users were lucky to have 16 MB, and too many still had 8 MB. Most of that was being used by Netscape. The gorgeous Apple Dylan IDE also required 24MB to run well, and most developer machines couldn't handle it.
I remember those numbers, because I worked for a company that was trying to ship a browser plugin that would have required 24MB itself. Our project plan was totally infeasible.
I think a lot of ambitious projects died around 1997, because RAM prices stubbornly refused to drop.
The "select versus activate" distinction mentioned in the article also made for an absolutely miserable user experience. It's the only thing I remember about OpenDoc, trying to get components to activate.
Developers spent those years learning HTML and JavaScript and how to run a Linux server. The internet was obviously the main show, and weird semi-proprietary document formats were the last thing anyone cared about.
At least some of the Dylan content of the second link (and maybe other stuff, I didn't look too closely) also appears to be available more directly here:
Minor correction —- Jobs was a living legend at that point, but wasn’t CEO again, yet.
Not sure that it was a different world in the way you mean. Back then, as today, leaders of leading tech giants wouldn’t be in that setting taking questions from developers. It was a different Apple; one whose prospect of survival was in question, which needed developers not to abandon the platform, and needed employees not to abandon the company.
But it was certainly a different Apple. Can you imagine Cook, Federighi or Ternus on a theater taking any random question? I’d love that, but it’s not going to happen.
> Despite Apple's efforts to seed the technology, OpenDoc didn't get a lot of traction with developers and arguably even less with users, who didn't understand what it was good for.
I remember feeling exactly like that back then. I was enthusiastic about the "new thing" but whenever I tried installing and using it, I could never achieve anything.
I'm a little bit relieved now, because even after reading this well-written article, I still don't understand what it was supposed to do, what problem it was supposed to solve, and how it was supposed to be used.
I guess what it really needed was an initial bundle/collection of actually useful examples showing how to tap its potential, because I remember the technology sounding interesting at least.
> I'm a little bit relieved now, because even after reading this well-written article, I still don't understand what it was supposed to do, what problem it was supposed to solve, and how it was supposed to be used.
Microsoft has OLE, where you can paste an excel sheet in a word document (or vice versa), and third parties can similarly provide components that can be pasted inside word or excel documents.
OpenDoc tried to be that cross-platform without having applications such as word or excel having the special status of being able to host such components. Instead, you got a blank document. If you wanted to write a text document, you dragged in a word processor component.
The various ‘Works’ suites (Microsoft Works, ClarisWorks) worked like that, but weren’t extensible.
OpenDoc wanted to do it better, making it easier for third parties to get a piece of the pie (for example, adding new chart types should be trivial to do for users: buy/download the part (OpenDoc’s name for a component), and drag it into your Excel or ClarisWorks spreadsheet)
So, for end users, it would make it easier to combine everything they needed in a single document. A bit like Eclipse, but that only does rectangular tiles, and doesn’t, for example, allow text to flow around an illustration or web components, if there were a GUI that allowed you to build web pages by dragging them around on a blank page (who’s busy writing that?)
OpenDoc also tried to improve on OLE by not requiring users to click to activate a part so that you could interact with it.
Now, why didn’t it work out? It’s more complex than an office suite that’s not extensible, requires cooperation between competitors, hardware was too slow even for an implementation in C++ (which, apart from efficiency of compiled code, is the wrong language for implementing such a thing, but we didn’t have better), and the benefits for end users weren’t that large ¿yet?
I’m surprised I have Kantara listed anywhere, lol.
I had a few utilities. A window manager, for example. And PartBank was the registry and online store for software. Important, because if you open the document and you are missing software, it was impossible to view. But since I had a registry of viewers and how to install them, it solved a few problems. I spoke at WWDC and MacWorld about these things. This was the App Store I wanted bundled into the OS.
I had another utility called Kantara Internet Search Service (KISS). My young baby self had gotten a deal to sell 1 million copies of it to Apple to include on the install for education. Steve Jobs killed that deal too. Sigh.
Like most webservices these days, your app runs in a Linux instance in a Docker container in a VM running another OS running on a physical server running another OS.
That was a nice walk down memory lane. I worked for CI Labs for about a year and published a book on OpenDoc that was released just as the project was canceled. C'est la vie!
I worked on things like the standardization of the naming registry, and a bunch of behind-the-scenes coordination with Apple. The team was pretty small; I had worked on CORBA when I was at Sun, so I also did some work with SOM.
Modern icons are mostly useless. I remember old apple design guidelines recommending to design icons with recognizable shapes. iPhone icons are all square making impossible to identify the right one at a first glance. Same for the MacOS dock.
“he's really funny about ideas. If you tell him a new idea, he'll usually tell you that he thinks it's stupid. But then, if he actually likes it, exactly one week later, he'll come back to you and propose your idea to you, as if he thought of it."[1]
Yeah, he said the built-in software store was stupid alright, but it was a decade later that the App Store came out.
This takes me back to 1996. It was a dark time for fans of the Mac, but there was some really cool stuff they were doing. HyperCard wasn’t quite dead yet either.
On a complete tangent I lost a fair bit of that summer to the online multiplayer tank game Bolo.
can't agree. yeah you were expecting them to go under each day, and OS-development slowed to a crawl (7.5.x releases seemingly dragged on forever).
but things were moving in the right direction, technology was exiting and the future even more so.
compare that to now, where things have been moving in the wrong direction for decades now and each day there is more lockdown, surveillance and user/consumer-hostile nonsense.
the past's future didn't turn out freeing and exciting, but boring, depressing, restricting and homogeneous.
i remember when these compound documents with embedded objects were all the rage in the 90s. in microsoft land it was all ole and activex (which seems like it ultimately only saw real use as a browser plugin standard).
seems the most interesting one was the japanese system that recently graced these pages, can't remember the name now...
It’s hard not to think this 90s “document turducken” trend was driven by engineers, rather than coming out of any real user need. We still don’t work this way, though it would be easier than ever now with web technology. It turns out, links work just fine and are dramatically simpler on both a conceptual and technical level.
I agree. Though the “spreadsheet table in a document” use case was always the first demo, and is still a common use case. It was probably also the only real use case with any staying power.
"Chart based on a spreadsheet that you can update later" is the real place it shines. If you try to have two documents, the spreadsheet always gets lost.
I was an idealist at the time and was very much on board with SOM (system object model by IBM COM was Microsoft model). The people who truly knew what they were doing always had turnsout position.
Cyberdog was the only application I used as my daily drivers for all things internet. None of the other exampls ended up being useful in anyway.
My guess is that SOM and COM are the type of tech only a behemoth could love.
Cyberdog was the only good use of OpenDoc I ever saw, and it was never interesting as a part of OpenDoc. It was just really good set of internet apps that happened to be implemented as OpenDoc parts. If the developers had implemented them as regular Mac apps, Apple would have been ahead of the game.
Turnsout stated in the earlier post that it wasn't practical. I was responding that I remember disregarding the same sentiment from people trying to teach me.
I thought cyberdog was great and definitely used until as my mine internet app for mail and browsing until at IE 5 on Aqua and Mail.app.
That was my point—you can do all kinds of things on the web now, but people don’t really create these multi source meta-documents. Unless you count a TikTok embed or something.
looks like there's some limited cross application embedding support in google docs, so i'd argue you're right except for one glaring exception....
jupyter notebooks and donald knuth's literate programming dream.
duh duh dunnnnn. crash
buut. to your point, maybe there's a fable in there. existing large systems should be coupled in interface and presentation, but not necessarily in implementation!
Only sort of. <iframe> can embed arbitrary web content, but this power is only available if you're writing bare HTML. Apps like Google Docs which ordinary users can actually use don't actually give you this power. Their internal document models aren't HTML and they don't even render to DOM anymore, they render to canvas.
Furthermore there's a growing movement to slowly deprecate certain embedding use cases. Embedded sites could always pop themselves out of the current page, but there's now also HTTP headers that let you explicitly forbid embedding on either end. This is actually considered a security best practice[0] as there are crafty XSRF attacks that could be enabled by, say, layering an invisible iframe in front of your cursor that just so happens to be open and scrolled to the "send all my money to someone" button on your bank account. Timing attacks apparently also rely on embedding, so anyone who wants to use, say, shared-memory multithreading for WASM[1] has to also opt out of both being embedded and being allowed to embed other sites.
[0] According to people begging for bug bounty money
Agreed. Also, IFrames don't really compose well, or give easy communication between parent and child IFrames in the same way that components can set attributes and call methods on each other
Present tense, a lot of custom controls work using this technology. COM has had the spotlight of Windows APIs since Windows Vista took the .NET ideas for Longhorn and re-did them in COM/C++.
My guess is that the name is from the Preston character in the 1995 Wallace and Gromit short A Close Shave, which would have premiered a couple of months before the first beta.
The Cyberdog email client featured the first appearance of the Advanced Technology Group's V-Twin indexed search engine. We take instantaneous search for granted today, but back then it was a game changer.
Technical mailing lists were the most common way new information about technologies were shared, and instantaneous search was very handy.
Since the author (classichasclass) seems to be reading the comments, I'll mention this here...
The article mentions "The OpenFileService part provided a menu option which would dynamically generate a Cyberdog item to a file reference using the Standard Open dialogue [...] to the best of my knowledge is now lost".
A file containing the OpenFileService part does seem to be available here, as part of Cyberdog 2.0 browser install[0][1]:
When it extracted it contains a folder named "OpenFileService 1.0.1 ƒ" which contains `OpenFileService` and a README file.
I found this while investigating some other related items and will attempt to update/edit this comment with some links (but wanted to at least mention this now in case I disappear down some other rabbit hole :) ).
Other CyberDog versions on CD found on archive.org (unverified due to online viewer seemingly not able to handle Mac-compatible ISOs) which may also have other relevant content:
The Internet Archive also has a CyberDog datasheet, "Getting Started" manual and couple of other items.
I found the above items on archive.org after initially looking on https://ftpmirror.your.org/ and http://bitsavers.org which I've had success with in the past when looking for historical info/binaries, especially from archived FTP sites.
While neither site appears to have specific archives of the CyberDog FTP site, I did find a number of OpenDoc & CyberDog related items (including SDK-related) which I'll aim to add links for below.
I also owned WAV (an OpenDoc word processor). I was way too far ahead of the curve.