elliott@veronica.cs.wisc.edu (James Elliott) (04/11/91)
An unfortunate trend in Mac applications in the last few years has been to cram more and more functionality into a single application. Thus we have "word processors" that also edit tables and graphics, do math, keep databases, and generally try to be everything to everyone. This just doesn't make sense to me. Lotus 1-2-3 was great on systems where you could only run one program at a time, and in the age when different programs were unable to conveniently share objects. So why do we have MS-Works on the Mac, which is a completely different kind of environment? The problem with the "do it all" style of programming is that it's very hard to get EVERYTHING right. A particular company might implement an excellent text editing system, which I find responsive and a delight to use. However, the graphics editing capabilities that they felt necessary to include may well not be what I need (and, if they are an afterthought included in order to jump on the super-functionality bandwagon, they're likely to be pretty poor). So I'll want to use a different program to create graphics for my documents. But, if I want to use the aforementioned nice text processor, I am saddled with the cost of the its graphics portions, which I don't ever use. Cost in terms of application size, memory requirements, dollar investment, and generally energy on the part of the development team that could have been better spent on making the program's strength (the good text processing) even stronger. In theory, the unified environment of the Macintosh should be taken advantage of by writing lean applications that are very, very good at one particular thing, and which can share their expertise in flexible ways with other applications. That way, individual users can put together a "super-application" that suits us >exactly<, by purchasing individual components that we prefer, and using them in a coordinated fashion. Now that multitasking exists, and real inter-application communication is coming (with things like "live" copy-paste, i.e. publish and subscribe), I hope that we can get closer to achieving this goal. I'm not too optimistic that it will happen, though. After all, from the beginning the Mac was supposed to work this way, at least to a degree... and even as Switcher and MultiFinder became realities, application bloat seemed to accelerate. I don't know what market forces have been leading in this unfortunate direction, but I hope that when System 7 finally comes out, it will present an opportunity for users and developers alike to step back and think about what Mac applications should be and how they should fit together. It seems to me that shrinking the focus of applications while strengthening their seamless and transparent sharing of objects is the way to go. It will lead to less wasted code, space and time, better thought-out and implemented approaches to specific problems, and will help the vast (and growing) user community to come up with their own creative ways of putting pieces together into unique solutions. -- Jim Elliott "Like a bridge he'll come between us, not a wall" elliott@veronica.cs.wisc.edu
elliott@veronica.cs.wisc.edu (James Elliott) (04/11/91)
[If this appears twice, I'm sorry; the Pnews attempt at posting it hung and I killed it after 20 minutes.] An unfortunate trend in Mac applications in the last few years has been to cram more and more functionality into a single application. Thus we have "word processors" that also edit tables and graphics, do math, keep databases, and generally try to be everything to everyone. This just doesn't make sense to me. Lotus 1-2-3 was great on systems where you could only run one program at a time, and in the age when different programs were unable to conveniently share objects. So why do we have MS-Works on the Mac, which is a completely different kind of environment? The problem with the "do it all" style of programming is that it's very hard to get EVERYTHING right. A particular company might implement an excellent text editing system, which I find responsive and a delight to use. However, the graphics editing capabilities that they felt necessary to include may well not be what I need (and, if they are an afterthought included in order to jump on the super-functionality bandwagon, they're likely to be pretty poor). So I'll want to use a different program to create graphics for my documents. But, if I want to use the aforementioned nice text processor, I am saddled with the cost of the its graphics portions, which I don't ever use. Cost in terms of application size, memory requirements, dollar investment, and generally energy on the part of the development team that could have been better spent on making the program's strength (the good text processing) even stronger. In theory, the unified environment of the Macintosh should be taken advantage of by writing lean applications that are very, very good at one particular thing, and which can share their expertise in flexible ways with other applications. That way, individual users can put together a "super-application" that suits us >exactly<, by purchasing individual components that we prefer, and using them in a coordinated fashion. Now that multitasking exists, and real inter-application communication is coming (with things like "live" copy-paste, i.e. publish and subscribe), I hope that we can get closer to achieving this goal. I'm not too optimistic that it will happen, though. After all, from the beginning the Mac was supposed to work this way, at least to a degree... and even as Switcher and MultiFinder became realities, application bloat seemed to accelerate. I don't know what market forces have been leading in this unfortunate direction, but I hope that when System 7 finally comes out, it will present an opportunity for users and developers alike to step back and think about what Mac applications should be and how they should fit together. It seems to me that shrinking the focus of applications while strengthening their seamless and transparent sharing of objects is the way to go. It will lead to less wasted code, space and time, better thought-out and implemented approaches to specific problems, and will help the vast (and growing) user community to come up with their own creative ways of putting pieces together into unique solutions. -- Jim Elliott "Like a bridge he'll come between us, not a wall" elliott@veronica.cs.wisc.edu