Linux-Advocacy Digest #720, Volume #28 Tue, 29 Aug 00 00:13:06 EDT
Contents:
Re: Inferior Engineering of the Win32 Platform - was Re: Linsux as a desktop
platform ("Erik Funkenbusch")
Re: Linux, XML, and assalting Windows ("paul snow")
Re: Inferior Engineering of the Win32 Platform - was Re: Linsux as a desktop
platform ("Erik Funkenbusch")
Re: Linux, XML, and assalting Windows ("paul snow")
----------------------------------------------------------------------------
From: "Erik Funkenbusch" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Inferior Engineering of the Win32 Platform - was Re: Linsux as a desktop
platform
Date: Mon, 28 Aug 2000 22:56:15 -0500
"D. Spider" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >They were generally accepted to be:
> >Runs as many DOS and Win16 applications as possible
> >Runs Win32 apps
> >Can use DOS drivers
> >Runs in 4MB of RAM
> >Has pre-emptive scheduling
>
> It only fails on one of those then - the RAM requirements, obviously.
Obviously? Win95 ran in 4MB or ram. And it did so equally as fast as Win
3.1 did. Of course it ran MUCH faster than Win 3.1 when you had 8-16MB of
ram, but that wasn't the requirement.
> Well, whether you would call it that or not, it's demonstrably true,
> both in abstract and concrete. In abstract, it is a much better match
> to the principles of human engineering, in concrete, they are
> demonstrably better in terms of the time that someone with no previous
> experience takes to learn to use them, and how quickly people that use
> them can accomplish standard tasks. This is the result of the fact
> that Apple focused very much on usability, a very large amount of the
> research done on the subject has been sponsored by Apple, and their
> earlier interfaces reflected this very clearly.
Those studies were conducted by apple, or apple sponsored. MS has similar
studies which show the opposite.
> >That I'll have to disagree on. I find menus in Windows to be better at
> >higher resolutions and with multiple monitors. This may have something
to
> >do with the low mouse tracking speed of MacOS, however. Pop-up menus
under
> >the mouse are probably the most efficient method, but have
discoverability
> >issues.
>
> "Context menus" are great, but that doesn't obviate the usability
> problems with the main menu bar. Consider the difference in the fine
> muscle movement to activate the menu bar with a mouse on the Windows
> box compared to the Mac. With the Windows style, you have a relatively
> small target to aim for, a rectangle a few pixels on a side. It's
> usually around 7-8 times as wide as it is deep. Because of that lack
> of depth, the typical movement to access it is to grab the mouse,
> wheel it quickly to the menu and overshoot, then reverse direction and
> move back more slowly until it is located. With the Mac layout, you
> have a rectangle, the same width, but with *infinite depth.* You
> simply cannot overshoot the thing, and therefore the reversal and the
> second, slower movement is completely avoided.
However, you have to move the mouse much farther distances, especially if
you have multiple monitors. (I remember using a full page monitor on the
Mac several years ago in which every time I wanted to access the menus I had
to track across two monitors and go to the top.)
> Small thing? Perhaps. But it's precisely the type of small touch that
> differentiates a poor gui and a good one. And to someone that is NOT a
> geek, it is often a much more significant difference than you or I
> would see it as.
This is all subjective. "Poor" and "Good" have no concrete meaning here.
> >The standard Start menu has, IIRC, exactly 2 layers above "Programs".
>
> But Programs is a layer itself, meaning you typically have a 3 layer
> menu, and in many cases 4. Sometimes even more.
The apple menu isn't much better.
> >To edit the Start Menu, you drag and drop to it. Ever since IE4 was
> >released, which was quite some time ago. A free upgrade, no less.
>
> That sounds good, you should try using it sometime though. There is no
> apparent way to control where on the menu you are dropping to, and
> more importantly, editing does not simply mean adding. Pruning off
> extraneous entries, moving things from place to place, are essential
> parts of editing, and there is no "intuitive" way to do these things.
Umm.. you drag it around in the menu. It highlights the area in which it
will move to. This is all highly intuitive. You delete by selecting an
item and pressing the delete key or right clicking (yes, still while in the
menu) and choosing delete.
Clearly you haven't used the start menu in many years.
> >Which guidelines are disregarded ? You can't drag and drop directly to
the
> >button for perfectly good reasons, and the dialog you get when you try to
> >explains exactly how to do it properly.
>
> Drag and drop 101 - you select an object, press and hold mouse-1, drag
> to destination, and release. That's how it's supposed to work, and
> that's what the guidelines say.
The taskbar buttons are not a "destination". Have you tried dragging an
icon onto program icon in the finder on the top right of the MacOS menubar?
Same deal.
------------------------------
From: "paul snow" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.text.xml,comp.os.linux.setup,comp.os.linux.misc
Subject: Re: Linux, XML, and assalting Windows
Date: Tue, 29 Aug 2000 03:43:20 GMT
> As a wise man said, any advanced technology would appear as magic to a
> primative. No wonder you are having trouble installing software and are
> hoping for miracle solutions. I on the other hand am not a primative I
> understand just how the software and hardware operate. I can assure you
> there is no magic involved. It is technology based on sound scientific
> principles that make the computers work. Do you know that programs can
> exist without computer storage? So your statement that storage defines
the
> software is a invalid.
No, I did not know programs can exist without computer storage.
I would be very, very interested to learn about this new model of
computation that isn't based Turing's model of computation. After all, if
Turing's tape isn't storage, what is it?
------------------------------
From: "Erik Funkenbusch" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Inferior Engineering of the Win32 Platform - was Re: Linsux as a desktop
platform
Date: Mon, 28 Aug 2000 23:21:01 -0500
"D. Spider" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >No, Windows 95's design goal was to provide maximum backwards
compatibility
> >with Windows 3.x while providing maximum 32 bit API support (which
includes
> >multitasking). Where those two contradict, Backwards compatibility has a
> >higher priority. Also, Win9x's design goal was to run on the same
hardware
> >that typical Windows 3.x machines were running on in 1995 and be as fast,
or
> >faster than Windows 3.x. All of which it achieved.
>
> It certainly did not provide backwards compatibility with Win3.1 in
> terms of user interface, and it certainly did NOT run as fast as
> Win3.1 on the same machine.
Backwards compatibility for applications and drivers. How can a user
interface be backwards compatible? Compatible with what?
Win95 (the original, first version released) *DID* run just as well in 4MB
of ram as Windows 3.1 on a 386. I know this because I was responsible for
benchmarking it for the company I worked for at the time. Windows 95 was
several times faster if you gave it about 8-16MB of memory.
> I was responsible for about 40 machines at
> the time, I am not just making stuff up. The one major advantage it
> did have, and the reason why it was adopted at all in my shop, was the
> expanded heap allocations, which solved a lot of major problems in
> 3.1. Machines that ran large complicated windows programs, using heap
> space extravagantly, like SPSS or Borland C, simply had to have it.
> The others didn't, and so I had the two running side by side on
> exactly the same hardware to observe.
Look, various benchmarks I tested say otherwise. Magazines such as PC Week
said otherwise (with detailed benchmarks).
> >Arguably. Lots of things run in kernel space on various Unix servers.
> >Linux now has a new kernel space web server. There are telnet servers
that
> >run in kernel space and sockets that run in kernel space.
>
> Which may or may not be a good idea, but the admin has control of
> that, and can run such a program or not. If he does, a case can be
> made for it, for instance on a single purpose web server, using mature
> code, you get a speed benefit to the one application that is the boxes
> reason for being, with very little cost. That argument cannot be made
> concerning video drivers, because they are not the servers reason for
> being, they are not part of its job description at all. The resources
> devoted to the web server would be used in any case - the resources
> devoted to the video routines would not. Any instability resulting
> from the web server can at least be balanced against improved server
> performance - but the video routines offer nothing at all to balance
> the instability they can cause.
Windows 2000 is proving to be more stable than Windows 3.51 (they moved the
drivers into the kernel in 4.0). Tell me again how this makes the OS
inherantly more unstable.
> >This is highly debateable. "ease of use" is a subjective measurement.
> >You're reading apples propoganda. Lots of people seem to think that
OS/2's
> >WPS is easy to use. My experience has been opposite.
>
> It's not a purely subjective measurement. Past experience definately
> plays a part in any subjective evaluation of it, but that simply means
> you must use non-subjective measurements - adherence to the basic
> principles of human engineering, and controls for the past experiences
> and preferences of test subjects.
Basic principles? You speak as if "human engineering" were a millenium old
practice.
Fact is, this is a buzzword created by apple. There are no "human
engineering" classes tought in "human engineering school".
Everything your quoting is apple propoganda and nothing more.
> >> Examples of these problems are not hard to find. Start with the
> >> placement of the window control widgets -
> >> minimise-maximise/restore-close clustered together is a poor design.
> >> The Mac OS9 and prior layout, placing close on the opposite corner
> >> from the others is a better design.
> >
> >Again, this is subjective. I don't find them to be a poor design at all.
> >Anywhere you put them, people will accidentally hit them.
>
> But placing them in one configuration will drastically increase the
> chances vs another configuration.
I have *NEVER* accidentally hit the close button. Ever. Not once.
> >> The placement of the menus - the Windows design where they are placed
> >> below the top window border is clearly an inferior design to the Mac
> >> placement of the menus along the top edge of the desktop.
> >
> >You say this without explaining why this is "clearly superior".
> >
> >Actually, I believe the Mac design is clearly inferior. The apple design
> >forces you to move the mouse to the top of the screen everytime you want
to
> >use a menu. With the Windows design, if your window is not maximized,
you
> >must only move the mouse to the top of the window.
> >
> >Why is this "clearly inferior"?
>
> I explained this in another post (and many of the other issues you
> raise,) but briefly, the target area for a windows style menu control
> is say (ballpark figure) 1/4"x1/8", whereas the effective target area
> for an equivelent menu control in the mac style is 1/4"xinfinity. It
> doesn't take a genius to see which one can be hit the quickest and
> easiest, and which one may require much more detailed, careful, and
> time consuming mouse manipulation.
It apparently does take a genius, since you can't seem to understand how
difficult this makes things in multi-monitor applications and how much extra
effort is expended moving the mouse to the top of the screen when you need
only move it a few inches.
> As to moving the mouse farther to get to the menu, while that is true,
> the more relevant issue is not the absolute distance traveled, but the
> difficulty of hitting the target, and the time it takes to do so. A
Difficulty in hitting the target? You're joking. This is a complete
non-issue for anyone who isn't handicapped or otherwise impaired. And for
those people special tools exist.
> very small, but precise, movement may be harder to do, and take more
> time and attention to accomplish, than a very large one in some cases.
So let me get this straight. Because, in a small number of cases, something
*MIGHT* require more effort, it's clearly inferior. Meanwhile, the *MUCH*
more common scenario of not having to move the mouse to the top of the
screen is clearly unimportant.
Right.
> This is one. By making sure the menu is always on a screen edge, the
> Mac designers insured that the window controls were effectively very
> big targets, without squandering screen space by actually making them
> big. Also, since they are always in the same place, motor memory
> quickly memorises them, much the same way someone that is used to
> keyboarding can activate functions with keystrokes much faster than
> they can reach for a mouse.
Tell me, why aren't dialog buttons also on the top of the screen? If it's
so important, why this radical change in philosophy of putting them
somewhere else?
> >> Ever try to drag and drop to an app running on the taskbar? Again,
> >> they went to the trouble to describe how drag and drop should work in
> >> their own guidelines, then disregard those guidelines entirely
> >> themselves.
> >
> >And what part of the guideline does this violate? I notice your
arguments
> >are getting to be more hand waving than substance as your argument rolls
on.
>
> No, it's not. See the other post. Drag-and-drop is not the same as
> Drag-and-hover-and-then-drag-some-more-and-drop. The application in
> this case is totally different from any other use of drag and drop.
The Mac uses the same interface when hovering over folders to expand them.
There is little difference between this and a minimized application.
> >There is a certain amount of inconsistency here. But I've seen lots of
Mac
> >apps that use inconsistent interfaces in the past as well.
>
> I never said Macs are the be-all and end-all. I pointed to them as an
> example of a better implementation of a GUI. At least until recently,
> these things were exceptions to the rule, a rule that Apple worked
> very hard to formulate, define, and enforce. None of which is true
> with windows.
You seem to contradict yourself. You say in one breath that certain things
violate MS UI standards, then in the next claim those standards do not
exist. Which is it?
> >> The Win95 common dialogs are bad enough (an inexplicable step back
> >> from the Win3.1 common dialogs in terms of UI design) but then MS puts
> >> out the Office package, which contains it's own unique and different
> >> implementations instead of using the common dialogues.
> >
> >Which end up in the next version of the OS. Windows 2000 has the Office
> >style common dialogs.
> >
> >What exactly is so bad about them? More hand waving?
>
> It's silly to make a common dialogue then not use it in your own
> application. Other than that, most of the criticisms that apply to the
> 95 common dialogues hold true. The windows 3.1 common dialogues were
> much better designed.
I disagree. I hate the 3.1 dialoges with a passion and find them more
difficult to use (They suffer from most of the same issues such as lack of
resizing, but are uglier and less useful).
> >Ahh yes. The user interface hall of shame. Some of it I can agree with,
> >other things are simply stupid. The author is himself rather arrogant,
> >proclaiming that things like buttons are intended to be shortcuts to menu
> >items and that they don't belong in a dialog (I guess he doesn't expect
the
> >user to be able to exit or cancel). Buttons are shortcuts to
functionality
> >which may or may not be present in the menu (not everything should be a
menu
> >item, otherwise you end up with thousands of menu entries).
>
> You misrepresent him. The primary objection to toolbar buttons in a
> dialogue is that they don't keyboard shortcuts - not a problem in a
> regular program window because the menus themselves contain the same
> functions and DO have shortcuts.
No. Toolbar buttons do *NOT* necessarily act as shortcuts to menus. They
can be functionality that doesn't exist in menus, or doesn't exist in the
users current menu configuration (since this can be adjusted by the user in
many apps, such as Office). When you have 1000 functions, you can't put
them all in menus.
And for your information, the buttons in the common dialog *DO* have
keyboard methods of use. Hit the menu key and navigate to the view menu, or
go to the new menu. Another thing the infamous hall of shame fails to
notice.
> >He also makes the proclamation that seperate windows for folders and
files
> >is the correct way of doing things. I disagree. A single, unified
> >interface is much easier to learn and use than seperate ones. Apple
> >understands this, which is why their finder has a unified interface.
>
> How is one to maintain context in a hierarchical file system without
> seeing the hierarchy? How much time does one want to spend every day
> scrolling past directories to find the files? Isn't the point of the
> entire dialogue to find a file?
A file might be in a folder. And if you know the name of your file, you
need only enter the first few characters and it will jump to that file.
It's VERY maneuverable and very flexible.
> I think you are very wrong here. The method of having different panes
> for files and for a context tree makes much more sense, at least as
> long as we use hierarchical file systems. You don't even need to have
> windows 3.1 around to see it on - explorer in win95 uses the two paned
> approach, and for a very good reason. That context is important.
It uses a two-paned approach, while still keeping folders in the right pane.
------------------------------
From: "paul snow" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.text.xml,comp.os.linux.setup,comp.os.linux.misc
Subject: Re: Linux, XML, and assalting Windows
Date: Tue, 29 Aug 2000 04:09:06 GMT
Bob Hauck <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Mon, 28 Aug 2000 02:28:10 GMT, paul snow <[EMAIL PROTECTED]> wrote:
> >Bob Hauck <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
>
> >> You've got it exactly backwards. Raw storage is just numbered blocks
> >> on the disk. Filesystems are an abstraction created by the OS.
>
> >No, you have it backwards. Where is the OS when your computer is off?
>
> In a pile of bits on the hard disk.
So, your OS is in storage. And Obviously that storage can be changed, so
long as the reasonable set of changes possible are documented. Or the
storage could be inspected against this documentation. Reconfigured if
necessary. New features added. In fact, anything that is documented, from
a storage point of view, can be done outside the OS. Because the OS is
nothing more than just another program, just so many bits on the hard disk.
Why not just give that point up?
All that about how you would have to stop the OS to manage it. Give that up
too. Surely you can figure out at least one way around that. I can think
of several, depending on the OS.
Then you might as well admit that what I am talking about is an organized,
standard form for what we do today. I have OS CDs and applications, etc. I
manually install them. Sure, lots of hand waving goes on, and it can be an
annoying process. But in the end, I transfer the abstract definitions from
this collection of static, issolated CDs into a rendering on the hard disk
of my machine. I supply all the answers to all the decision points.
Suppose the hard disk crashes. I can buy another, and assuming I can lay my
hands on all my CDs, I can rebuild my machine yet again (losing only my
unqiue work, if I failed to transfer it too to some external storage). And
I supply all the answers to all the decision points yet one more time.
Are you really saying no standard form, with a single separate install
facility for a given computer system can be reasonably define that is
equivilant to running a bunch of installs off a set of CDs?
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.advocacy) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
