Decisions like this should be based on more than someone's ideals.
If an ideal is that no stickers be put on, I can see a vast amount of wasted talent going into what is a nothing area. Even if it is embossed.
Ideals should be reserved for areas such as the best, GUI, ergonomics, functionality, presentation, cost, reliability, service, software, etc.
We don't need ideals to decide whether we will have a logo on a box, or a sticker on the machine. Most people rightfully would prefer the 5 or 10% discount on the price that having that sticker might make possible.
True. Ideals are NOT based on the use of stickers or the use of any other media. Rather, media is used to communicate and simbolize ideals. This has been true since the early days of graphic design. Apple can use their machines as another advertising medium for a huge company like Intel, or it can keep the machine's pristine design. I would gladly pay an extra 5-10% not to be having to stare at a company's poorly designed logo while I work.
True. Ideals are NOT based on the use of stickers or the use of any other media. Rather, media is used to communicate and simbolize ideals. This has been true since the early days of graphic design. Apple can use their machines as another advertising medium for a huge company like Intel, or it can keep the machine's pristine design. I would gladly pay an extra 5-10% not to be having to stare at a company's poorly designed logo while I work.
You would, and I might not mind either. I'm not constraind about price.
But, if we polled the general buying public, I'll bet they would disagree, strongly.
You can see that in a large organization, you can fix the problem with the software or hardware but equal or more attention must be payed to the health of the organization, fixing the problem is one of scope.
Or do what most UNIX programmers do: 'Fix' the user. Users must be fixed so they can use the software, no matter how convoluted the interface is.
A fresh appraisal of the desktop interface would take into account what we currently use computers for. If we use a wider use of the term "application" to mean how we use our computers, there are very few applications:
? Document creation (DTP apps have a similar document-centric interface)
? Console application (Many apps control some object, sometimes on a different server like IRC)
?_Notices (Information display, like widgets)
I don't see why there has to be zillions of interfaces, or even zillions of programs. For example, one application is enough for all document-creation needs. Do you really need a different interface for editing photos, audio, or text? The tools or commands would change depending on the context, but there is still the concept of a document. One could reasonably expect every document to have but one window, if a window at all. Given the simplicity of the shell "application," it could easily be replaced without changing the underlying model, or even the commands/tools.
Although it had flaws, the concept of OpenDoc has awesome potential for real-world productivity gains for programmer and user alike. One problem with OpenDoc was it was only designed for document purposes, not console or notices. We can learn from this too, and create a suitable middleware API for other purposes.
I could go on, but this isn't how things are evolving. The whole UNIX paradigm since 1969 is hack&fix until something works, taking little account of what gymnastics the user has to do. This has only gotten worse with the advent of UNIX graphical programs. The creature is not evolving as one unified being, but rather mutating and spreading like a bad virus.
The methodology is what I'm attacking here. That, and the zealotry.
Open Doc was a concept in search of a market. The software industry has been there, done that and spit it out as unpalatable. Too hard to get differint sotfware vendors to place nicely together. Not that it wouldn't be nice in a perfect world that did not reflect greed, but communism is like that too, and just as successful.
Open Doc was a concept in search of a market. The software industry has been there, done that and spit it out as unpalatable. Too hard to get differint sotfware vendors to place nicely together. Not that it wouldn't be nice in a perfect world that did not reflect greed, but communism is like that too, and just as successful.
Speaking as a former OpenDoc programmer and armchair economist, I would disagree on all your points.
First of all, OpenDoc had technical and marketing problems. The amount of work to get an OpenDoc 'Part' off the ground was a great technical barrier (which I only discovered in practice). The ported SOM model to Classic MacOS didn't work that well either. It was memory hungry for the times (nothing close to what a JVM eats though!). All things considered however, those technical problems would have gone away due to a) memory price and b) higher level abstractions making it easier for developers. Unfortunately Apple was bleeding red due to their Performa line disaster and pulled the plug on all projects not making money at the time. The rushed delivery was its death nell.
Second of all, you didn't need vendors to "place nicely together." The whole point of OpenDoc is if you followed the API, it would work with everything else. Vendors don't need to get along for applications to work together because they follow an IPC API.
Thirdly, the monolithic application vendors were against OpenDoc, and indeed Bill Gates at the time was interviewed and listed OpenDoc among his 10 greatest threats, but OpenDoc didn't need them to make parts anyway. This is more true now than ever.
Fourthly, Communism wouldn't work in an idealized greed-free world either. Communism fails not because of greed, but due to the inability to perform economic calculation. Ludwig von Mises proved as much when he published his essay "Economic Calculation In The Socialist Commonwealth" (1920) which became the basis for this book, "Socialism" (1922).
Speaking as a former OpenDoc programmer and armchair economist, I would disagree on all your points.
First of all, OpenDoc had technical and marketing problems. The amount of work to get an OpenDoc 'Part' off the ground was a great technical barrier (which I only discovered in practice). The ported SOM model to Classic MacOS didn't work that well either. It was memory hungry for the times (nothing close to what a JVM eats though!). All things considered however, those technical problems would have gone away due to a) memory price and b) higher level abstractions making it easier for developers. Unfortunately Apple was bleeding red due to their Performa line disaster and pulled the plug on all projects not making money at the time. The rushed delivery was its death nell.
Second of all, you didn't need vendors to "place nicely together." The whole point of OpenDoc is if you followed the API, it would work with everything else. Vendors don't need to get along for applications to work together because they follow an IPC API.
Thirdly, the monolithic application vendors were against OpenDoc, and indeed Bill Gates at the time was interviewed and listed OpenDoc among his 10 greatest threats, but OpenDoc didn't need them to make parts anyway. This is more true now than ever.
Fourthly, Communism wouldn't work in an idealized greed-free world either. Communism fails not because of greed, but due to the inability to perform economic calculation. Ludwig von Mises proved as much when he published his essay "Economic Calculation In The Socialist Commonwealth" (1920) which became the basis for this book, "Socialism" (1922).
The problems of OpenDoc can be directly laid at Apple's feet. Corel had a whole slew of software done or OpenDoc. So did others. But Apple dropped the ball there. The entire Copeland project went down in flames. some of it returned in small part in OS 9, but OpenDoc was allowed to die.
In a way I think it's a shame, but it could have only succeeded had it been designed differently. In spite of being middleware, the API was still monolithic in nature as every part had to implement a complete set of functions and the bento format wasn't interoperable. I suppose you could say the same about Office...
My only point in bringing it up was to challenge the whole <i>concept</i> of the application/program. If the dev environment was the interface, programs could run from that interface instead of a shell.
I just read the wikipedia entry for OpenDoc, and it's pretty good actually (especially the "Problems" and "Insider's Take" chapters):
In a way I think it's a shame, but it could have only succeeded had it been designed differently. In spite of being middleware, the API was still monolithic in nature as every part had to implement a complete set of functions and the bento format wasn't interoperable. I suppose you could say the same about Office...
My only point in bringing it up was to challenge the whole <i>concept</i> of the application/program. If the dev environment was the interface, programs could run from that interface instead of a shell.
I just read the wikipedia entry for OpenDoc, and it's pretty good actually (especially the "Problems" and "Insider's Take" chapters):
I still like the concept that Apple was trying with Newton, and to a certain extent with OpenDic.
That concept was that the program was the OS, and the OS was the program. Each new program added would become part of the whole, and that you could call up whatever part you needed for a particular use. You wouldn't find a "Finder" and programs to get, but rather a "sea" of parts floating within reach, just pluck out what you wanted. Everything would just work together.
An advanced concept, but it never really got off the ground. Really too bad.
I liked the concept, but really must say that we are closer to the dream of OpenDoc today than we've ever been: Cocoa's Frameworks.
There was an OpenDoc word processing module, web module (CyberDog), and a few more. Well, gee, you can build your own word processing app in just a few lines of ObjC and call straight to the frameworks that offer spell-check, font management, document window management, etc. We've got WebKit. If you took OpenDoc and moved the integration process a step or two back into the application design process, then you've got it right now, pretty much.
OpenDoc, the idea of being able to build suite applications based on individual lego-like parts, was a software engineering wet dream, not something that an end user would much think about. Sure, we might like to link Word and Excel (and MS did that for us), but a very, very small number of people would want to link a CAD program to Word with super tight integration. You might want to import a drawing image and even update it when it changed, but you'd not want to draw in new walls in Word....
That concept was that the program was the OS, and the OS was the program. Each new program added would become part of the whole, and that you could call up whatever part you needed for a particular use. You wouldn't find a "Finder" and programs to get, but rather a "sea" of parts floating within reach, just pluck out what you wanted. Everything would just work together
to me, that sounds a bit like how you work in a typical shell, with text files being a (very) primitive document standard...
Speaking as a former OpenDoc programmer and armchair economist, I would disagree on all your points.
First of all, OpenDoc had technical and marketing problems. The amount of work to get an OpenDoc 'Part' off the ground was a great technical barrier (which I only discovered in practice). The ported SOM model to Classic MacOS didn't work that well either. It was memory hungry for the times (nothing close to what a JVM eats though!). All things considered however, those technical problems would have gone away due to a) memory price and b) higher level abstractions making it easier for developers. Unfortunately Apple was bleeding red due to their Performa line disaster and pulled the plug on all projects not making money at the time. The rushed delivery was its death nell.
Second of all, you didn't need vendors to "place nicely together." The whole point of OpenDoc is if you followed the API, it would work with everything else. Vendors don't need to get along for applications to work together because they follow an IPC API.
Thirdly, the monolithic application vendors were against OpenDoc, and indeed Bill Gates at the time was interviewed and listed OpenDoc among his 10 greatest threats, but OpenDoc didn't need them to make parts anyway. This is more true now than ever.
Fourthly, Communism wouldn't work in an idealized greed-free world either. Communism fails not because of greed, but due to the inability to perform economic calculation. Ludwig von Mises proved as much when he published his essay "Economic Calculation In The Socialist Commonwealth" (1920) which became the basis for this book, "Socialism" (1922).
I liked the concept, but really must say that we are closer to the dream of OpenDoc today than we've ever been: Cocoa's Frameworks.
There was an OpenDoc word processing module, web module (CyberDog), and a few more. Well, gee, you can build your own word processing app in just a few lines of ObjC and call straight to the frameworks that offer spell-check, font management, document window management, etc. We've got WebKit. If you took OpenDoc and moved the integration process a step or two back into the application design process, then you've got it right now, pretty much.
OpenDoc, the idea of being able to build suite applications based on individual lego-like parts, was a software engineering wet dream, not something that an end user would much think about. Sure, we might like to link Word and Excel (and MS did that for us), but a very, very small number of people would want to link a CAD program to Word with super tight integration. You might want to import a drawing image and even update it when it changed, but you'd not want to draw in new walls in Word....
It's not quite the same thing. The idea wasn't to be able to build your own. Not from the users point of view. It should be transparent for the user.
The idea wasn't to link Word with a CAD program. The idea was to link PART of Word (or any text editor) to the PART of the CAD program that you needed at that moment. You could pull simple modules out as you needed them. from a menu perhaps. The way we pull the spell check into any program that can use it. Or the speech module.
But it isn't even that. Each module wouldn't necessarrily be part of one big program. Each would stand on its own, be integrated into the OS so that it could avail itself of the services of the OS natively.
So you could call a simple 2D CAD module to do a basic drawing, call a texteditor to do the descriptions and labels directly in the drawing, and then call up a spreadsheet module to enter the numbers for the costing process. Each module could be dismissed as soon as it was no longer needed, though the results would remain as part as the file you were working on. All files would fit into one extensible structure that every module could link with.
I know that this goes a bit further than the original idea, but not by much, and it does make sense. It would certainly enhance productivity, and require less memory.
Large programs like CAD/CAM are already broken into parts, but I'm talking about much finer granularity.
Good discussion following my posts -- I'm glad I posted and then didn't respond. Now that the discussion seems to have run its course I thought I would just toss in my response...
When looking at re-building a system it is usually more instructive (and more difficult) to look at the system's problems. The system's good features are usually designed into it based on good design practices/patterns, careful analysis of the requirements, and (hopefully) solid experience of the designer. The bad parts of the system are usually what was not considered or planned carefully. If you ignored the previous system and started again from scratch it is quite likely you'd go through more or less the same processes and end up with many or all of the good points... and most of the bad points.
Quote:
Those who ignore history are doomed to repeat it.
Now this is all a discussion of generalities, and there are always exceptions. Sometimes decisions are made at random or on an intuitive whim and they turn out to work wonderfully. Equally often they turn out dreadfully. All I'm saying is that when starting the redesign or refactoring process, take a look at the bad whims and the unconsidered elements first because that is probably your most fertile ground for improvement. The good parts are already good and it is usually straightforward to re-include them in your design, the bad parts can be deeply endemic and harder to eliminate.
This seemed to fail for the same reason the Taligent and Copland failed. Overly complex designs that put too much burden on the module/part developer. The intro to chapter 4 of Hillgrass' Cocoa programming book sums it up nicely -- he had a demo from one of the Taligent programmers, but when he asked for a fairly simple refinement to the demo, the Taligent guy got buried in the code needed to do it.
Much of this problem derives (pun intended) from the now dated notions about how and when to use object-oriented inheritance. NextStep was way ahead of its time in how it attacked OOD problem (or perhaps everyone was just behind the times for 10-20 years thanks to C++). I remember being quite enthused by some of the technology behind OpenDoc (SOM, in particular) until I tried to use it... then I went and found other more interesting things to do.
The rest of the problem comes from allowing too many programmers to get too caught up in the coolness of the thing they are building instead of obsessing about the coolness of what people will build with the thing they are build. This seems to happen a lot and I'm sure that almost all programmers have been guilty of it at some point in their careers (usually the early part before they learned better) -- evidently there were too many of them at Apple all at once in the early 90's.
A problem with the basic OpenDoc model (given that document-centric design is the way to go) is that its not clear that a generic system can express the potential interactions needed for satisfactorally integrated parts. It always felt a bit clunky in ways that a properly built app doesn't. And its not clear that you really want to combine all of those wonderful hypothetical things in a single document anyhow.
I'm not sure that I'd compare frameworks to OpenDoc in any way, but I do agree that frameworks looks like a much more successful software engineering paradigm.
It also didn't have the benefit of time to work out its problems. Apple's resources at the time were stretched, to say the least.
Copeland also failed because the groups working on it in their own separate areas put more emphasis into their own little worlds rather than seeing whether everything integrated. There was a great deal of secretiveness between the groups back then. Nothing successful ever comes out of uncoordinated efforts.
And its not clear that you really want to combine all of those wonderful hypothetical things in a single document anyhow.
Absolutely. And it's not only the need to combine a multitude of datatypes that is questionable, it is the very fact of this multitude in the first place. There are really only a few datatypes that most people need, and so a tightly integrated suite (e.g. Office) will do just fine.
Good discussion following my posts -- I'm glad I posted and then didn't respond. Now that the discussion seems to have run its course I thought I would just toss in my response...
When looking at re-building a system it is usually more instructive (and more difficult) to look at the system's problems. The system's good features are usually designed into it based on good design practices/patterns, careful analysis of the requirements, and (hopefully) solid experience of the designer. The bad parts of the system are usually what was not considered or planned carefully. If you ignored the previous system and started again from scratch it is quite likely you'd go through more or less the same processes and end up with many or all of the good points... and most of the bad points.
Now this is all a discussion of generalities, and there are always exceptions. Sometimes decisions are made at random or on an intuitive whim and they turn out to work wonderfully. Equally often they turn out dreadfully. All I'm saying is that when starting the redesign or refactoring process, take a look at the bad whims and the unconsidered elements first because that is probably your most fertile ground for improvement. The good parts are already good and it is usually straightforward to re-include them in your design, the bad parts can be deeply endemic and harder to eliminate.
I see your point, perhaps you saw mine?
my favorite quotes are;
Quote:
Those who throw out the baby with the bath water are doomed to repeat it.
and,
Quote:
Those who fix something that ain't broke are doomed to repeat it.
I'm sure many (if not most) of your OS ideas are quite good. However given the existing OS landscape (including applications and user base), starting over (I've lost count of how many times I have thought of this), while worthwhile, would be extremely difficult. In military lingo, "Lessons Learned," is extremely valuable (i. e. what do you (or can you) change going forward)).
To paraphrase Sir Isaac Newton;
The force (nee momentum) necessary to overcome the OS mass (nee inertia) would be HUMONGOUS!
or more precicely;
My'' + Cy' + Ky = F
where for linear 6-DOF rigid body motions and mass conservation, M, C, K are constants (6 by 6 matricies for mass, damping, and stiffness), F is the time dependent variable of forces and moments acting on the rigid body (6 by 1 vector), and y'', y', and y are (6 by 1 vectors for surge, sway, heave, roll, pitch, and yaw) the acceleration, velocity, and displacement of the rigid body. Usually, F is known (i. e. rocket engine thrust), and the equation is rewritten to solve for y (i. e. where is the Battlestar Galactica now).
Oh yes, absolutely. In no way do I advocate looking at only what went wrong, that would be silly. If a designer first internalizes what the problems are with the previous approach then he can search for better solutions while examining the existing ones. Having this context in fact makes the examination of what worked more useful.
This is much like going to a Stevenote aware of what he is going to announce -- it means you are much better prepared to critique it, and thus guard against the RDF. If you go in completely unawares the RDF is much more likely to sweep you off your feet.
Scrap the file metaphor and the filesystem along with it.
And replacing it with ...? I'm seriously curious because I think the desktop/file/folder metaphor is past its prime, regardless of its current stranglehold on computing. From a long-term usability perspective I don't see it scaling well.
Comments
Originally posted by melgross
Decisions like this should be based on more than someone's ideals.
If an ideal is that no stickers be put on, I can see a vast amount of wasted talent going into what is a nothing area. Even if it is embossed.
Ideals should be reserved for areas such as the best, GUI, ergonomics, functionality, presentation, cost, reliability, service, software, etc.
We don't need ideals to decide whether we will have a logo on a box, or a sticker on the machine. Most people rightfully would prefer the 5 or 10% discount on the price that having that sticker might make possible.
True. Ideals are NOT based on the use of stickers or the use of any other media. Rather, media is used to communicate and simbolize ideals. This has been true since the early days of graphic design. Apple can use their machines as another advertising medium for a huge company like Intel, or it can keep the machine's pristine design. I would gladly pay an extra 5-10% not to be having to stare at a company's poorly designed logo while I work.
Originally posted by RANSOMED
True. Ideals are NOT based on the use of stickers or the use of any other media. Rather, media is used to communicate and simbolize ideals. This has been true since the early days of graphic design. Apple can use their machines as another advertising medium for a huge company like Intel, or it can keep the machine's pristine design. I would gladly pay an extra 5-10% not to be having to stare at a company's poorly designed logo while I work.
You would, and I might not mind either. I'm not constraind about price.
But, if we polled the general buying public, I'll bet they would disagree, strongly.
And that's what matters.
Originally posted by Brendon
You can see that in a large organization, you can fix the problem with the software or hardware but equal or more attention must be payed to the health of the organization, fixing the problem is one of scope.
Or do what most UNIX programmers do: 'Fix' the user. Users must be fixed so they can use the software, no matter how convoluted the interface is.
A fresh appraisal of the desktop interface would take into account what we currently use computers for. If we use a wider use of the term "application" to mean how we use our computers, there are very few applications:
? Document creation (DTP apps have a similar document-centric interface)
? Console application (Many apps control some object, sometimes on a different server like IRC)
?_Notices (Information display, like widgets)
I don't see why there has to be zillions of interfaces, or even zillions of programs. For example, one application is enough for all document-creation needs. Do you really need a different interface for editing photos, audio, or text? The tools or commands would change depending on the context, but there is still the concept of a document. One could reasonably expect every document to have but one window, if a window at all. Given the simplicity of the shell "application," it could easily be replaced without changing the underlying model, or even the commands/tools.
Although it had flaws, the concept of OpenDoc has awesome potential for real-world productivity gains for programmer and user alike. One problem with OpenDoc was it was only designed for document purposes, not console or notices. We can learn from this too, and create a suitable middleware API for other purposes.
I could go on, but this isn't how things are evolving. The whole UNIX paradigm since 1969 is hack&fix until something works, taking little account of what gymnastics the user has to do. This has only gotten worse with the advent of UNIX graphical programs. The creature is not evolving as one unified being, but rather mutating and spreading like a bad virus.
The methodology is what I'm attacking here. That, and the zealotry.
Originally posted by Hiro
Open Doc was a concept in search of a market. The software industry has been there, done that and spit it out as unpalatable. Too hard to get differint sotfware vendors to place nicely together. Not that it wouldn't be nice in a perfect world that did not reflect greed, but communism is like that too, and just as successful.
Speaking as a former OpenDoc programmer and armchair economist, I would disagree on all your points.
First of all, OpenDoc had technical and marketing problems. The amount of work to get an OpenDoc 'Part' off the ground was a great technical barrier (which I only discovered in practice). The ported SOM model to Classic MacOS didn't work that well either. It was memory hungry for the times (nothing close to what a JVM eats though!). All things considered however, those technical problems would have gone away due to a) memory price and b) higher level abstractions making it easier for developers. Unfortunately Apple was bleeding red due to their Performa line disaster and pulled the plug on all projects not making money at the time. The rushed delivery was its death nell.
Second of all, you didn't need vendors to "place nicely together." The whole point of OpenDoc is if you followed the API, it would work with everything else. Vendors don't need to get along for applications to work together because they follow an IPC API.
Thirdly, the monolithic application vendors were against OpenDoc, and indeed Bill Gates at the time was interviewed and listed OpenDoc among his 10 greatest threats, but OpenDoc didn't need them to make parts anyway. This is more true now than ever.
Fourthly, Communism wouldn't work in an idealized greed-free world either. Communism fails not because of greed, but due to the inability to perform economic calculation. Ludwig von Mises proved as much when he published his essay "Economic Calculation In The Socialist Commonwealth" (1920) which became the basis for this book, "Socialism" (1922).
http://www.econlib.org/library/Mises/msS.html
Originally posted by strobe
Speaking as a former OpenDoc programmer and armchair economist, I would disagree on all your points.
First of all, OpenDoc had technical and marketing problems. The amount of work to get an OpenDoc 'Part' off the ground was a great technical barrier (which I only discovered in practice). The ported SOM model to Classic MacOS didn't work that well either. It was memory hungry for the times (nothing close to what a JVM eats though!). All things considered however, those technical problems would have gone away due to a) memory price and b) higher level abstractions making it easier for developers. Unfortunately Apple was bleeding red due to their Performa line disaster and pulled the plug on all projects not making money at the time. The rushed delivery was its death nell.
Second of all, you didn't need vendors to "place nicely together." The whole point of OpenDoc is if you followed the API, it would work with everything else. Vendors don't need to get along for applications to work together because they follow an IPC API.
Thirdly, the monolithic application vendors were against OpenDoc, and indeed Bill Gates at the time was interviewed and listed OpenDoc among his 10 greatest threats, but OpenDoc didn't need them to make parts anyway. This is more true now than ever.
Fourthly, Communism wouldn't work in an idealized greed-free world either. Communism fails not because of greed, but due to the inability to perform economic calculation. Ludwig von Mises proved as much when he published his essay "Economic Calculation In The Socialist Commonwealth" (1920) which became the basis for this book, "Socialism" (1922).
http://www.econlib.org/library/Mises/msS.html
The problems of OpenDoc can be directly laid at Apple's feet. Corel had a whole slew of software done or OpenDoc. So did others. But Apple dropped the ball there. The entire Copeland project went down in flames. some of it returned in small part in OS 9, but OpenDoc was allowed to die.
It's a shame really.
My only point in bringing it up was to challenge the whole <i>concept</i> of the application/program. If the dev environment was the interface, programs could run from that interface instead of a shell.
I just read the wikipedia entry for OpenDoc, and it's pretty good actually (especially the "Problems" and "Insider's Take" chapters):
http://en.wikipedia.org/wiki/OpenDoc
Originally posted by strobe
In a way I think it's a shame, but it could have only succeeded had it been designed differently. In spite of being middleware, the API was still monolithic in nature as every part had to implement a complete set of functions and the bento format wasn't interoperable. I suppose you could say the same about Office...
My only point in bringing it up was to challenge the whole <i>concept</i> of the application/program. If the dev environment was the interface, programs could run from that interface instead of a shell.
I just read the wikipedia entry for OpenDoc, and it's pretty good actually (especially the "Problems" and "Insider's Take" chapters):
http://en.wikipedia.org/wiki/OpenDoc
I still like the concept that Apple was trying with Newton, and to a certain extent with OpenDic.
That concept was that the program was the OS, and the OS was the program. Each new program added would become part of the whole, and that you could call up whatever part you needed for a particular use. You wouldn't find a "Finder" and programs to get, but rather a "sea" of parts floating within reach, just pluck out what you wanted. Everything would just work together.
An advanced concept, but it never really got off the ground. Really too bad.
I liked the concept, but really must say that we are closer to the dream of OpenDoc today than we've ever been: Cocoa's Frameworks.
There was an OpenDoc word processing module, web module (CyberDog), and a few more. Well, gee, you can build your own word processing app in just a few lines of ObjC and call straight to the frameworks that offer spell-check, font management, document window management, etc. We've got WebKit. If you took OpenDoc and moved the integration process a step or two back into the application design process, then you've got it right now, pretty much.
OpenDoc, the idea of being able to build suite applications based on individual lego-like parts, was a software engineering wet dream, not something that an end user would much think about. Sure, we might like to link Word and Excel (and MS did that for us), but a very, very small number of people would want to link a CAD program to Word with super tight integration. You might want to import a drawing image and even update it when it changed, but you'd not want to draw in new walls in Word....
Originally posted by melgross
That concept was that the program was the OS, and the OS was the program. Each new program added would become part of the whole, and that you could call up whatever part you needed for a particular use. You wouldn't find a "Finder" and programs to get, but rather a "sea" of parts floating within reach, just pluck out what you wanted. Everything would just work together
to me, that sounds a bit like how you work in a typical shell, with text files being a (very) primitive document standard...
Originally posted by strobe
Speaking as a former OpenDoc programmer and armchair economist, I would disagree on all your points.
First of all, OpenDoc had technical and marketing problems. The amount of work to get an OpenDoc 'Part' off the ground was a great technical barrier (which I only discovered in practice). The ported SOM model to Classic MacOS didn't work that well either. It was memory hungry for the times (nothing close to what a JVM eats though!). All things considered however, those technical problems would have gone away due to a) memory price and b) higher level abstractions making it easier for developers. Unfortunately Apple was bleeding red due to their Performa line disaster and pulled the plug on all projects not making money at the time. The rushed delivery was its death nell.
Second of all, you didn't need vendors to "place nicely together." The whole point of OpenDoc is if you followed the API, it would work with everything else. Vendors don't need to get along for applications to work together because they follow an IPC API.
Thirdly, the monolithic application vendors were against OpenDoc, and indeed Bill Gates at the time was interviewed and listed OpenDoc among his 10 greatest threats, but OpenDoc didn't need them to make parts anyway. This is more true now than ever.
Fourthly, Communism wouldn't work in an idealized greed-free world either. Communism fails not because of greed, but due to the inability to perform economic calculation. Ludwig von Mises proved as much when he published his essay "Economic Calculation In The Socialist Commonwealth" (1920) which became the basis for this book, "Socialism" (1922).
http://www.econlib.org/library/Mises/msS.html
Interesting for a rebuttal that you confirmed all my points. Thanks!
Originally posted by jccbin
OpenDic !?!?
I liked the concept, but really must say that we are closer to the dream of OpenDoc today than we've ever been: Cocoa's Frameworks.
There was an OpenDoc word processing module, web module (CyberDog), and a few more. Well, gee, you can build your own word processing app in just a few lines of ObjC and call straight to the frameworks that offer spell-check, font management, document window management, etc. We've got WebKit. If you took OpenDoc and moved the integration process a step or two back into the application design process, then you've got it right now, pretty much.
OpenDoc, the idea of being able to build suite applications based on individual lego-like parts, was a software engineering wet dream, not something that an end user would much think about. Sure, we might like to link Word and Excel (and MS did that for us), but a very, very small number of people would want to link a CAD program to Word with super tight integration. You might want to import a drawing image and even update it when it changed, but you'd not want to draw in new walls in Word....
It's not quite the same thing. The idea wasn't to be able to build your own. Not from the users point of view. It should be transparent for the user.
The idea wasn't to link Word with a CAD program. The idea was to link PART of Word (or any text editor) to the PART of the CAD program that you needed at that moment. You could pull simple modules out as you needed them. from a menu perhaps. The way we pull the spell check into any program that can use it. Or the speech module.
But it isn't even that. Each module wouldn't necessarrily be part of one big program. Each would stand on its own, be integrated into the OS so that it could avail itself of the services of the OS natively.
So you could call a simple 2D CAD module to do a basic drawing, call a texteditor to do the descriptions and labels directly in the drawing, and then call up a spreadsheet module to enter the numbers for the costing process. Each module could be dismissed as soon as it was no longer needed, though the results would remain as part as the file you were working on. All files would fit into one extensible structure that every module could link with.
I know that this goes a bit further than the original idea, but not by much, and it does make sense. It would certainly enhance productivity, and require less memory.
Large programs like CAD/CAM are already broken into parts, but I'm talking about much finer granularity.
When looking at re-building a system it is usually more instructive (and more difficult) to look at the system's problems. The system's good features are usually designed into it based on good design practices/patterns, careful analysis of the requirements, and (hopefully) solid experience of the designer. The bad parts of the system are usually what was not considered or planned carefully. If you ignored the previous system and started again from scratch it is quite likely you'd go through more or less the same processes and end up with many or all of the good points... and most of the bad points.
Those who ignore history are doomed to repeat it.
Now this is all a discussion of generalities, and there are always exceptions. Sometimes decisions are made at random or on an intuitive whim and they turn out to work wonderfully. Equally often they turn out dreadfully. All I'm saying is that when starting the redesign or refactoring process, take a look at the bad whims and the unconsidered elements first because that is probably your most fertile ground for improvement. The good parts are already good and it is usually straightforward to re-include them in your design, the bad parts can be deeply endemic and harder to eliminate.
This seemed to fail for the same reason the Taligent and Copland failed. Overly complex designs that put too much burden on the module/part developer. The intro to chapter 4 of Hillgrass' Cocoa programming book sums it up nicely -- he had a demo from one of the Taligent programmers, but when he asked for a fairly simple refinement to the demo, the Taligent guy got buried in the code needed to do it.
Much of this problem derives (pun intended) from the now dated notions about how and when to use object-oriented inheritance. NextStep was way ahead of its time in how it attacked OOD problem (or perhaps everyone was just behind the times for 10-20 years thanks to C++). I remember being quite enthused by some of the technology behind OpenDoc (SOM, in particular) until I tried to use it... then I went and found other more interesting things to do.
The rest of the problem comes from allowing too many programmers to get too caught up in the coolness of the thing they are building instead of obsessing about the coolness of what people will build with the thing they are build. This seems to happen a lot and I'm sure that almost all programmers have been guilty of it at some point in their careers (usually the early part before they learned better) -- evidently there were too many of them at Apple all at once in the early 90's.
A problem with the basic OpenDoc model (given that document-centric design is the way to go) is that its not clear that a generic system can express the potential interactions needed for satisfactorally integrated parts. It always felt a bit clunky in ways that a properly built app doesn't. And its not clear that you really want to combine all of those wonderful hypothetical things in a single document anyhow.
I'm not sure that I'd compare frameworks to OpenDoc in any way, but I do agree that frameworks looks like a much more successful software engineering paradigm.
Copeland also failed because the groups working on it in their own separate areas put more emphasis into their own little worlds rather than seeing whether everything integrated. There was a great deal of secretiveness between the groups back then. Nothing successful ever comes out of uncoordinated efforts.
This is where good management comes in.
Originally posted by Programmer
And its not clear that you really want to combine all of those wonderful hypothetical things in a single document anyhow.
Absolutely. And it's not only the need to combine a multitude of datatypes that is questionable, it is the very fact of this multitude in the first place. There are really only a few datatypes that most people need, and so a tightly integrated suite (e.g. Office) will do just fine.
Originally posted by Programmer
Good discussion following my posts -- I'm glad I posted and then didn't respond.
When looking at re-building a system it is usually more instructive (and more difficult) to look at the system's problems. The system's good features are usually designed into it based on good design practices/patterns, careful analysis of the requirements, and (hopefully) solid experience of the designer. The bad parts of the system are usually what was not considered or planned carefully. If you ignored the previous system and started again from scratch it is quite likely you'd go through more or less the same processes and end up with many or all of the good points... and most of the bad points.
Now this is all a discussion of generalities, and there are always exceptions. Sometimes decisions are made at random or on an intuitive whim and they turn out to work wonderfully. Equally often they turn out dreadfully. All I'm saying is that when starting the redesign or refactoring process, take a look at the bad whims and the unconsidered elements first because that is probably your most fertile ground for improvement. The good parts are already good and it is usually straightforward to re-include them in your design, the bad parts can be deeply endemic and harder to eliminate.
I see your point, perhaps you saw mine?
my favorite quotes are;
Those who throw out the baby with the bath water are doomed to repeat it.
and,
Those who fix something that ain't broke are doomed to repeat it.
strobe,
I'm sure many (if not most) of your OS ideas are quite good. However given the existing OS landscape (including applications and user base), starting over (I've lost count of how many times I have thought of this), while worthwhile, would be extremely difficult. In military lingo, "Lessons Learned," is extremely valuable (i. e. what do you (or can you) change going forward)).
To paraphrase Sir Isaac Newton;
The force (nee momentum) necessary to overcome the OS mass (nee inertia) would be HUMONGOUS!
or more precicely;
My'' + Cy' + Ky = F
where for linear 6-DOF rigid body motions and mass conservation, M, C, K are constants (6 by 6 matricies for mass, damping, and stiffness), F is the time dependent variable of forces and moments acting on the rigid body (6 by 1 vector), and y'', y', and y are (6 by 1 vectors for surge, sway, heave, roll, pitch, and yaw) the acceleration, velocity, and displacement of the rigid body. Usually, F is known (i. e. rocket engine thrust), and the equation is rewritten to solve for y (i. e. where is the Battlestar Galactica now).
Originally posted by franksargent
I see your point, perhaps you saw mine?
Oh yes, absolutely. In no way do I advocate looking at only what went wrong, that would be silly. If a designer first internalizes what the problems are with the previous approach then he can search for better solutions while examining the existing ones. Having this context in fact makes the examination of what worked more useful.
This is much like going to a Stevenote aware of what he is going to announce -- it means you are much better prepared to critique it, and thus guard against the RDF. If you go in completely unawares the RDF is much more likely to sweep you off your feet.
Originally posted by strobe
Scrap the file metaphor and the filesystem along with it.
And replacing it with ...? I'm seriously curious because I think the desktop/file/folder metaphor is past its prime, regardless of its current stranglehold on computing. From a long-term usability perspective I don't see it scaling well.