Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!nntp-server.caltech.edu!woody From: woody@nntp-server.caltech.edu (William Edward Woody) Newsgroups: comp.sys.mac.misc Subject: Re: give me solid facts: why is the mac better than MeSsy DOS/WINDOWS Message-ID: <1991Mar24.065427.16198@nntp-server.caltech.edu> Date: 24 Mar 91 06:54:27 GMT References: <1991Mar21.024213.9550@amd.com> <1991Mar22.050908.28727@nntp-server.caltech.edu> <1991Mar24.025913.29727@amd.com> Organization: California Institute of Technology, Pasadena Lines: 221 In article <1991Mar24.025913.29727@amd.com> phil@brahms.amd.com (Phil Ngai) writes: >woody@nntp-server.caltech.edu (William Edward Woody) writes: >> However, I may suggest that you may wish to limit your comments on >>to do with uniformity across applications, as this is a development >>issue, one you yourself have said (privately, I know) was not a concern of > >I thought we were talking about consistency seen by the users. Hmmmm. I guess I need to explain myself better, as I obviously didn't do such a good job the first time. Uniformity across applications may be determined by several factors. Some of them do with the amount of support provided by the operating system to allow a seemless integration and consistency of applications. Others have to do with the guidelines and application 'look and feel' standards set by the makers of the GUI interface (that is, how well the guidelines have been defined, how much support the GUI interface maker provides, how strongly those guidelines are pushed, and how well suited the GUI interface is to your particular application and to other applications similar, and different, from your application). 1) Operating system support. This has to do with such mechanisms as to how much code the underlying OS supports the ability for two applications to cut and paste between eachother, to present windows and menu items which have the same look and feel, and other such issues. This is principally a development issue, for if the OS supports the user interface, it will make it easier (in theory) for the developer to write code which supports that interface, thus increasing the number of compliant applications. On the other hand, if the OS doesn't support the interface (or at least support it well), then the chances are applications won't use the interface (or at least support it well). For the most part the Macintosh scores over MS Windows in this area, as far as I can see. [I develop for both platforms, so I think I am more qualified than someone who doesn't have experience on both platforms to make such judgements.] The 'clipboard' on the Macintosh supports multiple formats, and so an application who is getting information from the clipboard can in theory pick and choose from the formats for something it supports well. Under Windows it's a little more gross. One area where the Macintosh is sorely lacking, by the way, is in it's support of 'tear-off menu palettes', or floating palettes in general. Under Windows I can create a window which is constantly floating above it's parent window by simply specifying the window is a WS_CHILD and WS_OVERLAPPING to the CreateWindow function's style parameter. Under the Macintosh I have to write quite a lot of code to make sure my palette is above the other windows; it's not (currently) supported on the operating system. I don't believe the Macintosh is the perfect platform; just that it seems to be better than Windows on most areas where the operating system needs to support the consistant look-and-feel well-integrated suite of applications that work together seemlessly and across multiple hardware platforms. (This by the way is due to the fact that Apple is the single sole source of Macintosh computers, and the fact that Apple has been at the GUI business a hell of a lot longer than Microsoft.) 2) Standard Interface Guidelines The Apple Human Interface Guidelines (the bible, by the way, for anyone who is to develop a Macintosh application and is not certain what his application is supposed to look like) is very complete and (for the most part) completely reasonable for every aspect of your application. It is complete, very well thought out, and Apple makes it rather clear that they _strongly_ suggest that unless you have a good reason not to follow their guide, you should follow it to the letter. IMHO, the guidelines are completely impossible to live without. Shucks, I own two copies, one at home (next to my Macintosh which I'm using to write this responce--it's just above my keyboard next to my monitor), and one at work (where it lives next to the Macintosh I use to develop applications there). The IBM Systems Applications Architecture: Common User Access guidelines, on the other hand, are not quite as well thought out, and are not as strongly recommended by the authors of the guidelines (they're only guides, not gospel...) And (with the exception of the elements having to do with the necessity to support applications without mice), are not as complete by any stretch of the imagination as the Apple guidelines. Further, the attitude in the SAA CUA is "well, here's some guidelines. Follow them or not; shucks, we think they're okay." *SIGH* Though quite a few Windows developers seem to be falling all over themselves to support the SAA CUA, it's just a matter of making the keystroke accellerators match in the 'Edit' menu (which may or may not be there, and doesn't have to be the third menu bar item, after the system menu (Alt-Space), and the File menu). In fact, in order to make my Windows applications work with reasonable consistency, I follow the Apple Human Interface Guidelines when writing Windows applications! (Of course, when the SAA CUA bothers to have an opinion (which it doesn't do too often), I follow it instead. But for the most part those elements seem to be a subset of the more rigerous Apple Guidelines.) 3) Philosophic Support "It may seem that if a popular application 'pokes' the operating system and otherwise engages in unsavory practices that the authors or users of the application will suffer because a future release, such as OS/2, may not run the application correctly. To the contrary, the market dynamics state that the application has now set a standard, and it's the operating system developers who suffer because they must support that standard. Usually, that 'standard' operating system interface is not even known; a great deal of experimentation is necessary to discover exactly which undocumented side effects, system internals, and timing relation- ships the application is dependent on" -- Gordon Letwin, Microsoft's Chief Architect for System Software, "Inside OS/2". Quoted in "Undocumented DOS", page 22. In other words, Microsoft doesn't set the standards; instead, it is the market which determines the operating system standards. And through a bit of guessing and luck, you may be able to reverse-engineer the standards and (hopefully) keep future releases of the operating system from breaking. And you expect from a company such as this one to get a standard operating system interface which works for everyone seemlessly and without flaws and hidden gotchas? Be serious! Whenever you build an operating system with this sort of philosophy, it's just a matter of time before the entire house of cards comes falling down around your neck. Now, I quote from Apple, this time from their technical notes: "As a developer you play a key role in shaping the future of the Macintosh. By going beyond the guildlines in Inside Macintosh and the Macintosh Technical Notes and considering the effects of your design decisions on the whole Macintosh community, you allow the Macintosh to grow and change while still maintaining compatability. We won't break your applications, we can fully support features you desire, and we can implement these features in the best possible way for us, for you, and for the users. By going that extra step, you help us make programming the Macintosh simpler and ensure the best possible future for your products as well as ours." Apple Technical Note #227: Tookbox Karma The summary of Apple's position (in sharp contrast to that of Microsoft) is that not are you only to strictly follow their well documented interface standards, and not only are you to use only those interface options provided without 'going behind the operating system's back', but you need to also consider doing your thing using the most straight-forward and most obvious method possible. The quote above is almost a plea to the developers to make their applications consistent and compatable, and not to use dirty tricks which make life more difficult on everyone. Now tell me which philosophy is going to create a more robust system in the long run? -- Summary In short, you are correct: only the end-user can be the final judge in which operating system is more seemless and useable. However, CREATING such seemless applications and the support given in that creation process IS STRICTLY A DEVELOPER ISSUE. Yes, Windows is lightyears ahead of DOS in terms of it's usability and consistency; that is why I like doing Windows applications better than I like doing DOS applications. (I do Windows also because my employer thinks I'm a GUI guru, and hired me because I had experience on one platform--the Macintosh. He still hasn't figured out the work I had to do to get up to speed under MS Windows; he sorta thinks that a GUI is a GUI is a GUI...) However, the Macintosh is still lightyears ahead of Windows in terms of it's integration and ease of use, as well as in the integration of it's applications. Remind me to tell you about the time I posted about how my brother, on getting his new Macintosh IIsi, managed to put it together in about half- an-hour, without any help or any computer training (he's a musician in a rock-'n'-roll band). It contains the curious twist of the person from Apple writing me a private message saying essentially "that's interesting; our human engineering research suggests that the mean time to take someone who has never seen a computer before about 2 hours to unpack, plug in, and start using a Macintosh right out of the box." My god, they _researched_ the problem, and have been _analyzing_ the results, and _improving_ their products from these experiments! It sounds so simple and obvious to do this for the manual, or for the software, but for the box the computer comes in??? And when I watched my brother open the box and start assembling the Macintosh I was almost in tears. I was _moved_ that the box was so well engineered, so well put together, the proper manuals presenting themselves as the box unfolded, that it was almost a crime to have to open it. I swear with God as my witness that I have never seen a package so well engineered, so well thought out, so well _done_, from the very first time you open the very first box containing the Macintosh until it has been brought up and running with the latest software. And I have seen a lot of packages (and I mean ANY package--hell, I wasn't as impressed with my new 1991 Toyota MR-2 as I was with this simple computer!) And THAT is why I own a Macintosh, and THAT is why I believe that for the end-user, the Macintosh is currently the only way to go, and THAT is why I study the Apple manuals on Human Interface Guidelines, Documentation Guidelines, C Programming Style Guidelines, C++ Programming Style Guidelines and any other Apple guideline I can get my hands on RELIGIOUSLY. Because if I can help create a product which is even half as well engineered as my brother's Macintosh IIsi, I could then finally die happy, satisfied that I finally did something that was _right_. -- William Edward Woody | Disclamer: USNAIL P.O.Box 50986; Pasadena, CA 91115 | EMAIL woody@tybalt.caltech.edu | The useful stuff in this message ICBM 34 08' 44''N x 118 08' 41''W | was only line noise.