From: strobl@gmd.de (Wolfgang Strobl)
Subject: Re: Why Macs are better (and the others aren't)
Organization: GMD, Sankt Augustin, Germany
Date: Mon, 28 Sep 1992 22:26:59 GMT

In <kmhzd9n@rpi.edu> johnsd2@vccnw01.its.rpi.edu (Daniel Norman Johnson) writes:

>In article <strobl.717624432@gmd.de>, strobl@gmd.de (Wolfgang Strobl) writes:
>|> In <0_hzlck@rpi.edu> johnsd2@jec325.its.rpi.edu (Daniel Norman Johnson) writes:
>|> 
>|> >In article <strobl.717604304@gmd.de>, strobl@gmd.de (Wolfgang Strobl) writes:
>|> [...]
>|> >|> Perhaps because Microsoft has had to keep a standard look and 
>|> >|> feel for its applications on a bigger scale, which dosn't just 
>|> >|> include the Mac platform, only?
>|> 
>|> >Oh, c'mon.. Windows and the Mac aren't that different. Would it have
>|> >hurt THAT much to have Excel do real Cut+paste, for instance?
>|> 
>|> I don't know. "Real" Cut and Past mean different things on MS-Windows
>|> and on the Macintosh.

>Really? What are they under MS-Windows? I udnerstood they were
>the the same thing, from the users point of view.

It depends on the user, of course. The main difference is that on the
Macintosh, the exact interpretation of *what* is cut is done during
cutting time, while on WIndows it can (not must, *can*) be delayed
until pasting time. 

>|> >If you are saying the MS SHOULD make the Windows and MacOS versions
>|> >as close as possible, I disagree. This is annoying to people who
>|> >are using them and other apps on one machine. Id rather have it annoy
>|> >people who use just the one app, but do so on various machines.
>|> 
>|> What do the Human Interface Guidlines say about that topic?
>|> Probably nothing, because the Mac is a closed system.

>No, they say you should follow the Human Interface Guidelines
>and not do a port from some othe rsystem directly. They don't
>cover one-GUI-to-annother however (as far as I know, anyway)

What a pity! It really would have interested me to hear their
suggestions how to port Macintosh programs to other platforms
without violating the Human Interface Guidelines (and a few
other things) during that way. :-)

[laserprinter / paper, deleted for brevity]

>|> 
>|> The simple one to one relationship between data and its application
>|> doesn't work very well, in this and similar examples. In reality,
>|> it's a many-to-many relationship, where an application can understand
>|> various document types, and one document type can be understood by
>|> various applications. Both "application" (program) and "document" 
>|> (data) are concepts in their own right and depend on each other.
>|> Both are important.

>Yes! I agree!

>But the document is the center of it, to the user.
>He wants to do thing to it, not use app xyz. Wouldn't
>it be nice if he didn't have to muck about with use
>that app, ok now use this one...

Of course. But the simple minded one document to one application
linkage isn't a good implementation of that idea. OLE 1 and 2
seem to get into the near (and I'm sure that Apple has similar,
perhaps even better concepts). So we shouldn't waste our time
to compare one outdated and bad implementation of a theoretical
concept to another one.

[...]

>Ok. Thats just like the old, system 6 control panel (except
>that a control panel can BE a system extension; no extra
>steps be eithe rthe user or the installer are needed to make
>it work)

>The system 7 one, again, offers consitency; you add and remove
>stuff just like any old file, and so on. (Apple did a bunch of
>that stuff in system 7. Really just fixing user interface probs
>in system 6)

Well, I agree that Windows control panel could make good use 
of lot more drag & drop. 

[...]
>|> 
>|> >Anyway, I dont know when Multifinder came out, but we didn't need
>|> >DAs after that... although the apple menu didn't support non-DA-thing
>|> >until System 7. However, Windows did (and still doesn't) have an
>|> >Apple menu equivalent. Ya still gotta use teh program manager.
>|> 
>|> Not so. There are various shareware and payware utilities which
>|> extend the system menu (its functionality is partially shared
>|> by all apps) or the desktop (the background window, to be precise)
>|> to give similar functionality.

>I dont think we really want to drag extensions of various
>sorts into this. :) If so, the capablilities of both
>systems skyrocket, and nobody can be sure he's covered all
>the options. Fer instance, u want scripting in the MAcOS? Buy it!

This wasn't my argument. My argument was, that I tried and abadoned
that extension, because I had no real use (i.e. need) for it.
It was just an unnecessary complication. This disproves the
argument that something equivalent to the Apple menu is missing
on Windows.

>|> I have tried a few of them, myself,
>|> but found them not very usefull. Most people I talk to see a
>|> need for it, too.

>Waitasecond. You found them not very usefull, but most people
>you talk to see a need for it, *too*? huh?

Sorry - I'm doing my daily newsreading exercises during the
night, and modems are either fast or illegal to use or
expensive here in Germany, so I have to use a slow 2400
Baud modem from the PTT. This makes proofreading messages
a bit harder than usuall. I simply missed it. Of course I
intended to say: "Most people I talk to see no need
for it, too". I.e. it isn't my own, subjective experience,
only. Sorry for the confusion.

>|> This is perhaps because Windows doesn't use
>|> the "single menu bar at the top left of the screen" concept.

>I know; an apple menu as such would be inappropriate. But something
>like that. An addendum to the system menu, perhaps?

The extensions I tried do exactly that - they subclass the system
menu and use the standard menu editing system calls to add
their own stuff.

This doesn't work very well - in a way, the system menue of an
application is a system menu for *that* app, i.e. close *that*
app, or switch away from *that* app and so on. Application independent
functions don't belong there, imo. 

Adding functionality to clicks to the background are a much better
way to get "the systems" attention. Windows itself uses a double click
to the background window to activate the task manager. I've used
a utility which uses the *right* mouse button click to the 
background to launch some kind of launch/switch popup menu, on
occasion and found it moderately usefull.

Wolfgang Strobl
#include <std.disclaimer.hpp>
Newsgroups: comp.sys.mac.advocacy