From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-030 Date: Wed, 25 May 94 10:42:16 MET DST C.S.M.P. Digest Wed, 25 May 94 Volume 3 : Issue 30 Today's Topics: Apple's blatant disregard for User Interface Guidelines List Manager clikLoop problem... but whose it? Opening a file with C standard i-o routines Sym CDK vs CodeWarrior PPC: first impressions Where is the inheritance in AE objects? [Q] How to prevent _DragWindow from selecting the window? [Q] casting Str255 <--> (char*) The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users as comp.sys.mac.programmer.src. ------------------------------------------------------- >From jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) Subject: Apple's blatant disregard for User Interface Guidelines Date: 2 May 94 15:26:59 GMT Organization: Chevron, La Habra, CA Hello, I've been working on a presentation on Human Factors Engineering. I am using Apple's User Interface Guidelines as an example. What I would like to know is: Does Apple violate it's own Guidelines in any of it's System 7 software? If so, can I easily demonstrate it? Thanks in advance, John jjvbl@chevron.com -- =================================================================== John Blyzka | jjvbl@chevron.com "the BLITZ" | "only the good die young" +++++++++++++++++++++++++++ >From cwiltgen@mcs.com (Charles Wiltgen) Date: Tue, 03 May 1994 19:54:07 -0600 Organization: Lederhosen 'R' Us - Worldwide Leaders in Lederhosen In article <16674@lhdsy1.lahabra.chevron.com>, jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) wrote: > Hello, > I've been working on a presentation on Human Factors Engineering. > I am using Apple's User Interface Guidelines as an example. > What I would like to know is: > Does Apple violate it's own Guidelines in any of it's System 7 > software? > If so, can I easily demonstrate it? How 'bout dragging a disk to the trash to eject it? -- Charles Wiltgen "Love is a snowmobile racing across the tundra and cwiltgen@mcs.com then suddenly it flips over, pinning you underneath. (INTP) At night, the ice weasels come." - Nietzsche (Groening) World Wide Web http://venus.mcs.net/~cwiltgen/home.html +++++++++++++++++++++++++++ >From rmah@panix.com (Robert S. Mah) Date: Tue, 03 May 1994 21:57:11 -0500 Organization: One Step Beyond cwiltgen@mcs.com (Charles Wiltgen) wrote: > jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) wrote: > > > I've been working on a presentation on Human Factors Engineering. > > I am using Apple's User Interface Guidelines as an example. > > What I would like to know is: > > Does Apple violate it's own Guidelines in any of it's System 7 > > software? If so, can I easily demonstrate it? > > How 'bout dragging a disk to the trash to eject it? That is, in fact, a wonderful example of the _process_ of iterative user interface design. Complete with pragmatic compromises and soul searching about paradigm stability and all that. There was a thread over in comp.human-factors about this where one of Apple's Human Interface people stopped by and asked for suggestions. The winner got a T-shirt. Suffice it to say that no one could come up with anything better, given the constraints at hand. It's a pretty damn tough problem. Cheers, Rob ___________________________________________________________________________ Robert S. Mah -=- One Step Beyond -=- 212-947-6507 -=- rmah@panix.com +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Wed, 4 May 1994 11:13:39 GMT Organization: PRZ TU-Berlin jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) asked: >> Does Apple violate it's own Guidelines in any of it's System 7 >> software? >> If so, can I easily demonstrate it? cwiltgen@mcs.com (Charles Wiltgen) replied: >How 'bout dragging a disk to the trash to eject it? Although the semantics and history of this gesture have been much debated, I find myself asking "What Human Interface Principle does this violate?" It certainly supports the principles Direct Manipulation, See-and-Point, and User Control. Admittedly, it weakens the metaphor of trashcan- as-device-of-destruction, but since that's not what the trash can is (it's more a metaphor of device-to-get-things -off-my-desktop) and metaphors are meant to be *extensible* ("Metaphors in the computer interface suggest a use for something, but that use doesn't define or limit the implementation of the metaphor", _Macintosh Human Interface Guidelines_ p. 5), that's not really the problem. In short, although dragging a disk to the trash (as an alternative to the Put Away command) may seem to be a strange gesture, it's not a violation. As far was the original question is concerned, you can find a number of violations if you want to nit-pick. For instance, ResEdit 2.1.1 does not use the new, canonical layout for its "Maybe you want to save before closing/quitting?" dialog. Also, some of the recommendations regarding movabale modal dialogs and modeless dialogs were slow in percolating through to the entire system software. I think, however, you will be hard-pressed to find a violation in the Finder. Hope this helps, -- Peter Castine | Da sprach Jesus zu ihm: Stecke dein pcastine@prz.tu-berlin.de | Schwerdt an seinen Ort; denn wer das - ---------------------------------| Schwerdt nimmt, der soll durchs ``Have Mac, will travel'' | Schwerdt umkommen. (Matthai 26:52) +++++++++++++++++++++++++++ >From u9119523@sys.uea.ac.uk (Graham Cox) Date: Wed, 4 May 1994 20:24:52 GMT Organization: School of Information Systems, UEA, Norwich In article , cwiltgen@mcs.com (Charles Wiltgen) wrote: > In article <16674@lhdsy1.lahabra.chevron.com>, > jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) wrote: > > > Hello, > > I've been working on a presentation on Human Factors Engineering. > > I am using Apple's User Interface Guidelines as an example. > > What I would like to know is: > > Does Apple violate it's own Guidelines in any of it's System 7 > > software? > > If so, can I easily demonstrate it? > > How 'bout dragging a disk to the trash to eject it? Oh, THAT old chestnut! Be honest- could YOU live without it? Here's a trivial example- not in the system but in most graphics programs, including MacDraw and ClarisWorks- the guidelines say that the cursor keys should never be used to position graphic elements, but most programs do this. However, in my opinion, it is the guideline that's stupid- WHY NOT!!! > > -- > Charles Wiltgen "Love is a snowmobile racing across the tundra and > cwiltgen@mcs.com then suddenly it flips over, pinning you underneath. > (INTP) At night, the ice weasels come." - Nietzsche (Groening) > World Wide Web http://venus.mcs.net/~cwiltgen/home.html - ------------------------------------------------------------------------ Love & BSWK, Graham -Everyone is entitled to their opinion, no matter how wrong they may be... - ------------------------------------------------------------------------ +++++++++++++++++++++++++++ >From zz1bb@impending.ucsd.edu (Barry Brown) Date: 4 May 94 17:17:18 GMT Organization: (none) In <1994May4.111339.29072@prz.tu-berlin.de> pcastine@jake.prz.tu-berlin.de (Peter Castine) writes: >jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) asked: >>> Does Apple violate it's own Guidelines in any of it's System 7 >>> software? >>> If so, can I easily demonstrate it? >cwiltgen@mcs.com (Charles Wiltgen) replied: >>How 'bout dragging a disk to the trash to eject it? >Although the semantics and history of this gesture have been >much debated, I find myself asking "What Human Interface >Principle does this violate?" It certainly supports the >principles Direct Manipulation, See-and-Point, and User >Control. I believe it violates the (perhaps unwritten) "no surprises" and the "one object, one action" rules. A novice user is surprised to find out that trashing a disk doesn't erase it, but ejects it instead. S/he also discovers that selecting Eject from the Special menu doesn't remove the disk image from the desktop and may even ask him/her for the disk again in the future! Second, the Trash can is used for two purposes: removing files and ejecting disks -- two very different actions. The Trash is just a folder (albeit a special one); trashed files show up in its window before you empty it. Why don't trashed disks show up in it, either? -- Barry E. Brown Internet: bbrown@ucsd.edu UCSD Academic Computing Services AOL: BarryBrown Student Consultant My WWW Home Page +++++++++++++++++++++++++++ >From sjb8502@ucs.usl.edu (Bienvenu Jay ) Date: Wed, 4 May 1994 18:06:50 GMT Organization: Univ. of Southwestern La., Lafayette Does Claris count as part of Apple? If so, I've got one: MacWrite does not display a watch cursor while saving a file. Jay Bienvenu sjb8502@usl.edu +++++++++++++++++++++++++++ >From Paul Ferguson Date: 4 May 1994 23:48:17 GMT Organization: Kaleida Labs, Inc. In article <16674@lhdsy1.lahabra.chevron.com> John V. Blzka, jjvbl@lhdsy1.lahabra.chevron.com writes: > Does Apple violate it's own Guidelines in any of it's System 7 > software? One classic example that comes to mind is the Alarm Clock, which suffers from a bunch of violations: non-standard controls, non-standard title bar (not to mention using the title bar to display the time), non-standard close box, a cross-hair cursor to select a field, the big-small display modes, flashing the Apple menu forever when the alarm goes off (how many people at some point in their life were mystified to see a flashing alarm clock where the Apple menu is?) It's hard to find anything about the alarm clock that doesn't violate the HIG. Rumor has it that this DA was originally developed by Microsoft, which might explain some of it. It has not evolved at all from it's earliest incarnation, which is pretty lame on Apple's part. How hard is it to write an alarm clock? --fergy +++++++++++++++++++++++++++ >From Brad Koehn Date: 5 May 1994 01:35:32 GMT Organization: University of Wisconsin In article <1994May4.111339.29072@prz.tu-berlin.de> Peter Castine, pcastine@jake.prz.tu-berlin.de writes: >I think, however, you will be hard-pressed to find >a violation in the Finder. Oh, let's see, where to start: If you get info on a file on a server, or on a local volume with file sharing turned on, clicking on the name changes it to it's DOS equivilant. It doesn't give background applications any time (hardly). I know this probably isn't spelled out in the HIG, but it should be. When copying files, the menus don't dim. If you click in the menu bar during a copy, the dim all of a sudden. With the sharing box open, there's now way to save changes. You have to hit the close box, and dismiss the (up to three) annoying dialogs. Dragging items onto a system folder that's not the one you booted with doesn't put them in the right place, even if the icons in the folder (e.g. apple menu items folder) show correctly. You may call these bugs, but I say bugs are the most obvious form of HIG violation. _________________________________________________________________________ Brad Koehn Data Transformations, Inc. koehn@macc.wisc.edu +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Thu, 05 May 1994 10:03:13 +0800 Organization: Department of Computer Science, The University of Western Australia In article <1994May4.111339.29072@prz.tu-berlin.de>, pcastine@jake.prz.tu-berlin.de (Peter Castine) wrote: >I think, however, you will be hard-pressed to find >a violation in the Finder. OK, I've got a good one! Why, when you drag a file into a folder where there already exists a file of the same name, do you have the option of replacing the original. Why doesn't the Finder move it to the Trash??? OK, so maybe it's not a *real* HIG violation but it's really inconsistent and consistency is one of the central precepts of the HIG. Other (more obvious) problems become apparent when you install PowerTalk. Try the following... 1) Open your catalogue. 2) Drag a file into the catalogue window. 3) See Finder highlight catalogue window. 4) Let go. 5) See file zoom back to its original position. Or try this... 1) Open your catalogue. 2) Find a user record (either in your Personal Catalogue or in a PowerShare catalogue) and drag it to the catalogue window. 3) See Finder highlight catalogue window. 4) Let go. 5) Read dialog telling you that you can't do it because you don't have privileges. Question #1 Why does it highlight the window (in both cases)? Question #2 Why does it have different behaviour when it finally realises that it's failed? Basically AOCE's HI is severely broken in a lot of places. Unfortunately it's a Finder extension, which means that these problems appear to be Finder problems. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From alister@netcom.com (Rick Reynolds aka GreenGoo) Date: Thu, 5 May 1994 06:32:08 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) >How 'bout dragging a disk to the trash to eject it? I never really thought much about this issue but I think there should have been a disk drive icon on the desktop, always visable but somehow conveying to the user that a disk is inserted. When the user wants to change disks they can press an "eject" button on the icon. But alas that brings up the problem of having a control (which woule have to be smaller then other controls) on a Finder icon. Hmmm... -- Richard Reynolds alister@netcom.com "Most dreams are made of glass. You throw just one stone and then there goes your last window" -RJD +++++++++++++++++++++++++++ >From deguzman@binkley.math.uiuc.edu (Alan DeGuzman) Date: 5 May 1994 13:17:32 GMT Organization: Calculus&Mathematica at UIUC alister@netcom.com (Rick Reynolds aka GreenGoo) writes: >>How 'bout dragging a disk to the trash to eject it? >I never really thought much about this issue but I think there should >have been a disk drive icon on the desktop, always visable but somehow >conveying to the user that a disk is inserted. Uh, what about the disk's icon? Granted, it can be hidden behind windows, but I'd rather have what *I* want to stay on top of the desktop layer rather than some floating icons or whatever. >When the user wants >to change disks they can press an "eject" button on the icon. But alas >that brings up the problem of having a control (which woule have to be >smaller then other controls) on a Finder icon. Now you're on to something. How about letting every icon that is a volume have a 'switch' or 'button' drawn on (or near) the icon that let's you eject the volume (eject in the sense of "Put Away"). It could even be dimmed out for volumes that can't be "Put Away", like the startup volume. -- Alan A. DeGuzman "The problem with people is that they're only human." Calculus&Mathematica DISCLAIMER: "The University - Hobbes to Calvin from can't afford my opinions." 'The Indispensible Calvin and Hobbes' +++++++++++++++++++++++++++ >From tzs@u.washington.edu (Tim Smith) Date: 5 May 1994 13:52:44 GMT Organization: University of Washington School of Law, Class of '95 > I've been working on a presentation on Human Factors Engineering. > I am using Apple's User Interface Guidelines as an example. > What I would like to know is: > Does Apple violate it's own Guidelines in any of it's System 7 > software? > If so, can I easily demonstrate it? In the thingy that is used to select a color (get it by selecting "other..." for your highlight color in the Colors control panel, or double clicking on a palette entry in the pattern editor in the General control panel), they use a scroll bar to set brightness. I think this violates something in the User Interface Guidelines. --Tim Smith +++++++++++++++++++++++++++ >From Thomas Reed Date: 5 May 1994 15:00:06 GMT Organization: Washington University In article <2q9ih4$nhs@news.doit.wisc.edu> Brad Koehn, koehn@macc.wisc.edu writes: >It doesn't give background applications any time (hardly). I know this >probably isn't spelled out in the HIG, but it should be. I don't think that this kind of stuff is in the interface guidelines, though I can't say that for sure. Actually, the amount of time background applications get depends on the background application. Any application can grab as much or as little of the CPU time as it needs. That's how the Mac's cooperative multitasking works. >When copying files, the menus don't dim. If you click in the menu bar >during a copy, the dim all of a sudden. I think my menus dim, all except the Apple, Balloon Help, and Application (you know, the one on the far right) menus. If they don't dim, it's probably for one of two reasons: 1) you can use them even during a copy, or 2) you have an extension or control panel installed that does something with your menus. >With the sharing box open, there's now way to save changes. You have to >hit the close box, and dismiss the (up to three) annoying dialogs. Agreed on this one. It'd be nice if there was a friendlier way to do sharing stuff. Though I'm not going to complain too much -- I don't mind the way it's done now. >Dragging items onto a system folder that's not the one you booted with >doesn't put them in the right place, even if the icons in the folder >(e.g. apple menu items folder) show correctly. Yes, I've often done this. However, there's really only one way for the computer to know that a folder is the system folder without doing more stuff than it should have to do -- if it has the active system in it. If every time you dropped something in a folder, the system had to search that folder for a copy of the Finder, then all your moves would take a little longer. Not only that, but it wouldn't be reliable -- sometimes I keep copies of the Finder around in different places to play with them. -Thomas ===================================================== Thomas Reed Washington University Reed@telesphere.wustl.edu Medical School (also: Reed@medicine.wustl.edu) - --------------------------------------------------- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain ===================================================== +++++++++++++++++++++++++++ >From Paul Ferguson Date: 5 May 1994 15:30:12 GMT Organization: Kaleida Labs, Inc. In article <2qatnc$bon@news.u.washington.edu> Tim Smith, tzs@u.washington.edu writes: > In the thingy that is used to select a color (get it by > selecting "other..." for your highlight color in the Colors > control panel, or double clicking on a palette entry in the > pattern editor in the General control panel), they use a scroll > bar to set brightness. I think this violates something in the > User Interface Guidelines. HIG page 215: "Use scroll bars only for representing the relative position of the visible portion of a document and in scrolling lists." I suppose one could argue that in the color picker, the "document" is the entire color space and that you are scrolling through it to see different views. On the other hand, what the slider is doing is changing the brightness from 0-65535, which is exactly what the example shown on that page says is an incorrect use of a scroll bar. This does raise the issue of why Apple explicitly talks about sliders (in a section entitled "Controls Not Supported by the Macintosh Toolbox") and gives guidelines as to their use, but have never provided any sort of standard slider controls for programmers to use. Other environments like Motif provide slider widgets with the same look and feel as their scroll bars, check boxes, etc. I think Apple's OS and UI groups have failed by not providing the same. Hence the scroll bar often does get misused because it is much easier to use what's there than write it from scratch (and writing a smooth slider is not a trivial task). --fergy - ------------------------------------------------------------------ Paul Ferguson | "It's a sick world, I'm a happy guy..." pferguson@kaleida.com | - ------------------------------------------------------------------ +++++++++++++++++++++++++++ >From hades@coos.dartmouth.edu (Brian V. Hughes) Date: 5 May 1994 17:33:26 GMT Organization: Dartmouth College, Hanover, NH, USA Thomas Reed writes: >Brad Koehn, koehn@macc.wisc.edu writes: >>It doesn't give background applications any time (hardly). I know this >>probably isn't spelled out in the HIG, but it should be. >I don't think that this kind of stuff is in the interface guidelines, >though I can't say that for sure. No it's not in the HIG, but that's because there is no human interface involved with background applications getting CPU time. >Actually, the amount of time background applications get depends on the >background application. Any application can grab as much or as little >of the CPU time as it needs. That's how the Mac's cooperative >multitasking works. Nope, sorry. There's this little routine called WaitNextEvent() that must be called, at a decent interval, by the forgroung application so that when the background application calls GetNextEvent() there's something there to be gotten. Applications have to be written to perform as both foreground and background apps, nicely, so that the Mac cooporative scheme works the way it's supposed to. -Hades +++++++++++++++++++++++++++ >From Chuck Simciak Date: Thu, 5 May 1994 17:28:00 GMT Organization: Cleveland Clinic Foundation In article <2qatnc$bon@news.u.washington.edu> Tim Smith, tzs@u.washington.edu writes: >> I've been working on a presentation on Human Factors Engineering. >> I am using Apple's User Interface Guidelines as an example. >> What I would like to know is: >> Does Apple violate it's own Guidelines in any of it's System 7 >> software? >> If so, can I easily demonstrate it? I'm not sure if this counts as breaking an interface guideline but it is very annonying. Say I go to save a file, the StandardPutFile dialog emerges and I have to navigate several folders to get to my desitination. The file name field has already been filled with a defualt. Here's the catch. Upon having navigated the multiple folders to place the file, the SAVE button is now an OPEN button. I then have to click in the filename text field to cause the button to CHANGE to SAVE. This "feature" was introduced in System 7 and has been a source of nuisance ever since. later.... Chuck Simciak !"The broken image of Man moves in minute by minute wxs@po.cwru.edu ! and cell by cell... Poverty, hatred, war, police- simciac@ccsmtp.ccf.org ! criminals, bureaucracy, insanity, all symptoms of WRUW 91.1 FM Cleveland ! The Human Virus." - William S. Burroughs +++++++++++++++++++++++++++ >From dn_crow@bean.open.ac.uk (dn_crow) Date: Thu, 5 May 1994 18:43:00 GMT Organization: (none) An example that has always rather amused me is the one about switching between applications. The guidlines state that if I click outside any window belonging to my application, this action should switch me to the application whose window I have clicked over (e.g. the Finder). The only action of this click, or indeed double-click, should be to switch applications. In particular, the guidelines state that the clicks should *not* be sent to the application being clicked upon. However, the Finder disregards this: try loading an application and bringing it to the front, while still being able to see a finder window behind it. If you now click over a visible finder icon, the appropriate Finder window is brought to the front (correct) but the icon is selected (incorrect). This, along with most of the other problems mentioned in this thread, is pretty minor, so if, as your rather biased title suggests, you're trolling for Apple-bashing material, I think you'll have a pretty weak case... Dan +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Thu, 5 May 1994 19:48:30 GMT Organization: PRZ TU-Berlin quinn@cs.uwa.edu.au (Quinn "The Eskimo!") writes: >pcastine@jake.prz.tu-berlin.de (that's me) wrote: > >>I think, however, you will be hard-pressed to find >>a violation in the Finder. > >OK, I've got a good one! Why, when you drag a file into a folder where >there already exists a file of the same name, do you have the option of >replacing the original. Why doesn't the Finder move it to the Trash??? >OK, so maybe it's not a *real* HIG violation but it's really inconsistent Inconsistent with what? >and consistency is one of the central precepts of the HIG. Consistency is, IMHO, a secondary concern. Smith et.al. discuss the practical issues of maintaining consistency in real world applications in their 1982 article "Designing the Star user interface." (Originally printed in Byte 7(4), reprinted in Baecker & Buxton's _Readings in Human-Computer Interaction_, the paper is a must-read). Short precis: consistency is the hobgoblin of small minds. >Other (more obvious) problems become apparent when you install PowerTalk. This is cheating--PowerTalk extensions aren't the Finder. I suppose they look that way, though. >Try the following... > >1) Open your catalogue. >2) Drag a file into the catalogue window. >3) See Finder highlight catalogue window. >4) Let go. >5) See file zoom back to its original position. > This example comes practically straight from the discussion in the above-mentioned article. Geez--maybe I should just violate copyright and type in the entire paper. :-) >Or try this... > >1) Open your catalogue. >2) Find a user record (either in your Personal Catalogue or in a >PowerShare catalogue) and drag it to the catalogue window. >3) See Finder highlight catalogue window. >4) Let go. >5) Read dialog telling you that you can't do it because you don't have >privileges. > >Question #1 Why does it highlight the window (in both cases)? For performance reasons? (Checking privileges might slow down feedback, direct manipulation. I'm obviously guessing on this one). >Question #2 Why does it have different behaviour when it finally realises > that it's failed? What's it supposed to do? Not tell you that it failed? Disregard privileges? >Basically AOCE's HI is severely broken in a lot of places. Severely? Well, I'll let that pass before a flame war breaks out. > Unfortunately >it's a Finder extension, Like I said, cheating. >which means that these problems appear to be >Finder problems. Well, touche. -- Peter Castine | Da sprach Jesus zu ihm: Stecke dein pcastine@prz.tu-berlin.de | Schwerdt an seinen Ort; denn wer das - ---------------------------------| Schwerdt nimmt, der soll durchs ``Have Mac, will travel'' | Schwerdt umkommen. (Matthai 26:52) +++++++++++++++++++++++++++ >From Thomas Reed Date: 5 May 1994 20:31:38 GMT Organization: Washington University In article <1994May5.172800.22102@bme.ri.ccf.org> Chuck Simciak, simciac@ccsmtp.ccf.org writes: > The file name field has already been filled with a defualt. Here's the >catch. Upon having navigated the multiple folders to place the file, the >SAVE button is now an OPEN button. I then have to click in the filename >text field to cause the button to CHANGE to SAVE. This "feature" was >introduced in System 7 and has been a source of nuisance ever since. I believe this problem is caused not by the system, but by Directory Assistance II. (Or a similar program.) My System 7.x machine never did this until I installed Directory Assistance II, so... -Thomas ===================================================== Thomas Reed Washington University Reed@telesphere.wustl.edu Medical School (also: Reed@medicine.wustl.edu) - --------------------------------------------------- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain ===================================================== +++++++++++++++++++++++++++ >From Thomas Reed Date: 5 May 1994 20:48:08 GMT Organization: Washington University In article <2qbal6$3tu@dartvax.dartmouth.edu> Brian V. Hughes, hades@coos.dartmouth.edu writes: >>Actually, the amount of time background applications get depends on the >>background application. Any application can grab as much or as little >>of the CPU time as it needs. That's how the Mac's cooperative >>multitasking works. > > Nope, sorry. There's this little routine called WaitNextEvent() that >must be called, at a decent interval, by the forgroung application so >that when the background application calls GetNextEvent() there's >something there to be gotten. Yes, it's true that there has to be "something to be gotten", but I think most applications these days, background or not, call WaitNextEvent, so they can control directly how much time they get by giving different numbers for the sleep value. A low value causes the app to be given time more often, a high value causes the app to be given time less often. Plus, if the background app doesn't call WaitNextEvent AT ALL for a while, they get ALL of that processing time. WaitNextEvent is the key behind applications getting CPU time. -Thomas ===================================================== Thomas Reed Washington University Reed@telesphere.wustl.edu Medical School (also: Reed@medicine.wustl.edu) - --------------------------------------------------- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain ===================================================== +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Thu, 5 May 1994 20:39:17 GMT Organization: PRZ TU-Berlin Chuck Simciak writes: > >I'm not sure if this counts as breaking an interface guideline but it is >very annonying. Say I go to save a file, the StandardPutFile dialog >emerges and I have to navigate several folders to get to my desitination. > The file name field has already been filled with a defualt. Here's the >catch. Upon having navigated the multiple folders to place the file, the >SAVE button is now an OPEN button. I then have to click in the filename >text field to cause the button to CHANGE to SAVE. This "feature" was >introduced in System 7 and has been a source of nuisance ever since. I like this one, because the Standard Save File dialog is being *consistent* (that's right, folks!). The Save button only changes to Open when you've selected a folder in the directory list. When this is the case, the EditText field with the document name is no longer the active item in the dialog, the directory list is the active item (highlighted with an extra two-pixel thick box surrounding it). So, the Save button is being context-sensitive, changes to 'Open' and behaves the same way a double-click on the currently selected item would behave. BTW, you don't need to click on the document name, you only have to deselect any folder, for the button to change back to Open. I'm just waiting for someone to say "Why don't they add another button, so you've got one for Save and one for Open?" Before you ask that question, read Tognazzini's article on Consistency in _The Art of Human-Computer Interface Design_ ;-q -- Peter Castine | Da sprach Jesus zu ihm: Stecke dein pcastine@prz.tu-berlin.de | Schwerdt an seinen Ort; denn wer das - ---------------------------------| Schwerdt nimmt, der soll durchs ``Have Mac, will travel'' | Schwerdt umkommen. (Matthai 26:52) +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Fri, 06 May 1994 10:41:44 +0800 Organization: Department of Computer Science, The University of Western Australia In article <2qatnc$bon@news.u.washington.edu>, tzs@u.washington.edu (Tim Smith) wrote: >In the thingy that is used to select a color (get it by selecting "other..." >for your highlight color in the Colors control panel, or double clicking >on a palette entry in the pattern editor in the General control panel), >they use a scroll bar to set brightness. I think this violates something >in the User Interface Guidelines. Actually it violates the letter, *but not IMHO the spirit*, of the guideline that states that you should only put settings, as opposed to commands, in a popup menu. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From jfinete@cats.ucsc.edu (Joseph Manuel Finete) Date: 6 May 1994 03:04:26 GMT Organization: University of California; Santa Cruz In article <1994May5.203917.29612@prz.tu-berlin.de> pcastine@jake.prz.tu-berlin.de (Peter Castine) writes: > >I like this one, because the Standard Save File dialog is being >*consistent* (that's right, folks!). > >The Save button only changes to Open when you've selected a folder >in the directory list. When this is the case, the EditText field >with the document name is no longer the active item in the dialog, >the directory list is the active item (highlighted with an extra >two-pixel thick box surrounding it). So, the Save button is being >context-sensitive, changes to 'Open' and behaves the same way >a double-click on the currently selected item would behave. > >BTW, you don't need to click on the document name, you only have >to deselect any folder, for the button to change back to Open. Also, hitting the TAB key will let you cycle through the dialog items. So if the file list is selected, hit TAB and then the EditText field will be selected. My problem is that its not obvious enough that the file list is selected or that the Edit Text field is not selected, although, I really don't have a good idea on how to alleviate this. -- Joe Finete jfinete@cats.ucsc.edu +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 6 May 1994 08:34:14 GMT Organization: The Royal Institute of Technology In <1994May5.172800.22102@bme.ri.ccf.org> Chuck Simciak writes: >catch. Upon having navigated the multiple folders to place the file, the >SAVE button is now an OPEN button. I then have to click in the filename >text field to cause the button to CHANGE to SAVE. This "feature" was Or you can press TAB. This is so you can actually type-select folder names in the list, instead of having to use arrow keys. Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe (on a Swedish scale) -- What we need is a good GNU [...] licence manager implementation. -- Raphael Manfredi +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 6 May 1994 08:36:21 GMT Organization: The Royal Institute of Technology In <1994May5.184300.25982@leeds.ac.uk> dn_crow@bean.open.ac.uk (dn_crow) writes: >only action of this click, or indeed double-click, should be to switch >applications. In particular, the guidelines state that the clicks >should *not* be sent to the application being clicked upon. This recommendation is going away with the new, direct manipulation, Drag Manager, and AOCE which uses it (or its cousin) and it will DEFINATELY not be the case when you run OpenDoc. Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe (on a Swedish scale) -- What we need is a good GNU [...] licence manager implementation. -- Raphael Manfredi +++++++++++++++++++++++++++ >From sw@network-analysis-ltd.co.uk (Sak Wathanasin) Date: Fri, 6 May 94 09:47:25 GMT Organization: Network Analysis Ltd In article <1994May5.184300.25982@leeds.ac.uk> (comp.sys.mac.advocacy,comp.sys.mac.programmer), dn_crow@bean.open.ac.uk (dn_crow) writes: > applications. In particular, the guidelines state that the clicks > should *not* be sent to the application being clicked upon. As with all guidelines, this is not meant to be slavishly adhered to. It's up to the appl whether to accept the first click, and in the case of the Finder what it does makes a lot of sense. Although the desktop is a window in some sense, in a way it isn't. You have to select a piece of paper (window) to write in it, but surely you don't expect to "select" your desk to pick something up or put it down. (I'd also argue that you should be able to "click through" to most appls, just like I can scribble a note in the margin of a sheet of paper without having to move it to the front, but that's another story.) The Finder also does the same with folder windows. Does anyone remember what it used to be like? When you wanted to drag a file from one folder to another, you clicked on the src icon which would bring its window to the front. This would sometimes cover up the window you wanted to drag to, so you'd have to go back and move it out from underneath (then move it back after the drag if you're obsessively tidy like me :-). The way it does it now is MUCH better, and I'm pleased to see that the Drag Mgr supports this way of working. If the guidelines say that you can't do this, then the guidelines should be changed. Sak Wathanasin Network Analysis Limited 178 Wainbody Ave South, Coventry CV3 6BX, UK Internet: sw@network-analysis-ltd.co.uk uucp: ...!uknet!nan!sw AppleLink: NAN.LTD Phone: (+44) 203 419996 Mobile:(+44) 850 587411 Fax: (+44) 203 690690 +++++++++++++++++++++++++++ >From Willie Abrams Date: 5 May 1994 15:02:28 GMT Organization: OU Health Sciences Center In article Quinn, quinn@cs.uwa.edu.au writes: >Basically AOCE's HI is severely broken in a lot of places. Unfortunately AOCE is real screwed up as far as HIG goes. If we are going to flame its flaws, here are my complaints: The standard mailer is a specific size, which means if you make the window smaller, it cuts off the damn mailer, and if you make the window bigger, you can't take advantage of the extra space to the right of the mailer. The way the mailer is shaped, You can only see about three enclosures... AppleMail has a real sluggish event loop. I know this isn't necessarily a HIG flaw, but it is a real UI flaw. I end up reading mail in ClarisWorks, since it responds to my stimulus faster. PowerShare admin stuff is just plain ugly. Chicago and Geneva are the System and Application typefaces for a reason - they are readable on screen. This Palatino stuff, with fixed sixed panes are a real pain. At least with AppleShare, you had nice resizeable and movable lists that allowed you to manage it. (although it didn't remember window positions...ugh!) I can move the keys off the desktop, but I can't move the catalogs (I guess I can sort of see that) - QuickDraw GX suffers there too, with all of those desktop printers...a real pain in the butt for those of use who move frequently from enviroment to enviroment with the same system. Another UI problem - Symantec/Think C - I can't open a source file without opening a project. Great! Modal Functionality... Probably why I like Metrowerks... Is there a forum where people can talk and discuss about UI issues? Would that be a thread that should be here in csmp? I think we have a real opportunity to jolt some people back into thinking about how software is used. There are real usability issues that are not related to functionality that need to be addressed. We as programmers need to address these head on, as we implement the great (or horrid) user interfaces. I will stop now. I am getting incensed. Willie Abrams Telemedicine Software Guy Internet: willie-abrams@uokhsc.edu OU Health Sciences Center AppleLink: Willie +++++++++++++++++++++++++++ >From John Hamilton Slye Date: Fri, 6 May 1994 12:55:38 -0400 Organization: Junior, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA On 06-May-94 in Re: Apple's blatant disrega.. user Joseph Manuel Finete@cat writes: >Also, hitting the TAB key will let you cycle through the dialog items. >So if the file list is selected, hit TAB and then the EditText field >will be selected. My problem is that its not obvious enough that the >file list is selected or that the Edit Text field is not selected, >although, I really don't have a good idea on how to alleviate this. When the test field is not selected, the caret isn't in it anymore...and when the file list is selected, there is an outline box around it... O------------------O---------------------O----------------------------------O | | jsbr@andrew.cmu.edu | "I know that there are people in | | J. Hamilton Slye | | the world who do not love their | | | ham@ece.cmu.edu | fellow human beings...and I HATE | O------------------O---------------------O people like that!" | | 1071 Morewood Ave. | - Tom Lehrer | | Pittsburgh, Pa. 15213 O----------------------------------O | (412) 862-3739 | THIS SPACE FOR RENT! | O----------------------------------------O----------------------------------O +++++++++++++++++++++++++++ >From Robert Hess Date: Fri, 6 May 1994 18:44:40 GMT Organization: MacWEEK In article Quinn, quinn@cs.uwa.edu.au writes: >Other (more obvious) problems become apparent when you install PowerTalk. Oh, I have an even better one... A letter sits in the In Tray. I drag it out of the In Tray into a folder. Have I moved the letter? No, I've copied it. The copied letter and the letter remaining in the In Tray, appear to be identical (same icon, same name). In one window I can see the sender date sent, etc. In another window I see size, date modified, etc. Can I modify the name of something in the In Tray? No. How about in a folder? Yes. Can I move something from a folder back into the In Tray? No. I love PowerTalk but it imposes a whole set of new (i.e. inconsistent) rules on new users and, like you said, makes the Finder seem awkward. ======================================================================== Robert Hess, WEEKgeek robert_hess@macweek.ziff.com MacWEEK AppleLink: WNDZSX 301 Howard CompuServe: 72511,333 San Francisco, Calif. 94105 America Online: MacWEEK (415) 243-3576 days MCI: RHESS (415) 243-3651 fax (415) 647-5549 nights I speak for myself. now doesn't that make you feel better? And sometimes not even that. ======================================================================== +++++++++++++++++++++++++++ >From Robert Hess Date: Fri, 6 May 1994 18:46:25 GMT Organization: MacWEEK In article Quinn, quinn@cs.uwa.edu.au writes: >1) Open your catalogue. >2) Find a user record (either in your Personal Catalogue or in a >PowerShare catalogue) and drag it to the catalogue window. >3) See Finder highlight catalogue window. >4) Let go. >5) Read dialog telling you that you can't do it because you don't have >privileges. Or, better yet, drag a user record into the "mount points" list of the File Sharing Monitor. It hightlights, indicating it is willing to accept a drag. Why on Earth would it do that? (Or, for that matter, why would someone try to do this? But that's not the point. ;) ======================================================================== Robert Hess, WEEKgeek robert_hess@macweek.ziff.com MacWEEK AppleLink: WNDZSX 301 Howard CompuServe: 72511,333 San Francisco, Calif. 94105 America Online: MacWEEK (415) 243-3576 days MCI: RHESS (415) 243-3651 fax (415) 647-5549 nights I speak for myself. now doesn't that make you feel better? And sometimes not even that. ======================================================================== +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Fri, 6 May 1994 19:43:02 GMT Organization: PRZ TU-Berlin Willie Abrams writes: > >Is there a forum where people can talk and discuss about >UI issues? Would that be a thread that should be here in csmp? > How about comp.human-factors? That might have been a more appropriate place to follow-up. -- Peter Castine | Da sprach Jesus zu ihm: Stecke dein pcastine@prz.tu-berlin.de | Schwerdt an seinen Ort; denn wer das - ---------------------------------| Schwerdt nimmt, der soll durchs ``Have Mac, will travel'' | Schwerdt umkommen. (Matthai 26:52) +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Fri, 6 May 1994 20:03:56 GMT Organization: PRZ TU-Berlin Joseph Manuel Finete@cat writes: >>Also, hitting the TAB key will let you cycle through the dialog items. >>So if the file list is selected, hit TAB and then the EditText field >>will be selected. My problem is that its not obvious enough that the >>file list is selected or that the Edit Text field is not selected, >>although, I really don't have a good idea on how to alleviate this. John Hamilton Slye responded: > >When the test field is not selected, the caret isn't in it anymore...and >when the file list is selected, there is an outline box around it... I think Joseph may have been aware of this behavior. It is, however, a bit on the subtle side. It becomes more obvious when the EditText field is entirely selected, because it highlights/unhighlights when you tab in and out of it. -- Peter Castine | Da sprach Jesus zu ihm: Stecke dein pcastine@prz.tu-berlin.de | Schwerdt an seinen Ort; denn wer das - ---------------------------------| Schwerdt nimmt, der soll durchs ``Have Mac, will travel'' | Schwerdt umkommen. (Matthai 26:52) +++++++++++++++++++++++++++ >From jaeger@kunikpok.icus.com (Jaeger) Date: Fri, 06 May 94 13:20:30 CDT Organization: Kunikpok Kennels and Komputers (Pet Project) Here's a blatantly diregarded interface guidline. When formatting floppies there is no progress indicator. Anything that takes as long as formatting a floppy should have a progress bar. Brian Stern :-{)} Jaeger@fquest.com +++++++++++++++++++++++++++ >From mikec@mv.mv.com (Mike Callaghan) Date: Fri, 6 May 1994 21:51:04 GMT Organization: MV Communications, Inc. In article <1994May5.184300.25982@leeds.ac.uk>, dn_crow wrote: >However, the Finder disregards this: try loading an application and >bringing it to the front, while still being able to see a finder window >behind it. If you now click over a visible finder icon, the appropriate >Finder window is brought to the front (correct) but the icon is >selected (incorrect). If I'm not mistaken, this is simple to correct with ResEdit by changing the Finder's SIZE resource (Get Front Clicks, I believe). Personally, I like it, and wish more programs did it. MikeC -- Michael D. Callaghan Nashua, New Hampshire - -------------------------------------------------------------------- RULE: "(sqrt(-1)) before (2.71828), except after (186,000 miles/sec)." [THE DANGERS OF MIXING GRAMMAR AND SCIENCE] +++++++++++++++++++++++++++ >From scgkr@mucc.mahidol.ac.th (Graham Keith Rogers - SCLG) Date: 7 May 1994 02:06:49 GMT Organization: Mahidol University, Thailand. Paul Ferguson (pferguson@kaleida.com) wrote: : select a field, the big-small display modes, flashing the Apple : menu forever when the alarm goes off (how many people at some : point in their life were mystified to see a flashing alarm clock : where the Apple menu is?) It's hard to find anything about the Is *that* what that is. Jeez, how do I turn it off? Please.... Graham +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 7 May 1994 09:03:08 GMT Organization: The Royal Institute of Technology In Robert Hess writes: >A letter sits in the In Tray. I drag it out of the In Tray into a folder. Have I >moved the letter? No, I've copied it. Of course! It's the same thing as "a file is sitting on a floppy disk, and I drag it to a folder on my hard disk." However, QuickDraw GX desktop printers are another thing: A file sits in the printer queue, and I drag it to the desktop. It is MOVED there. I then drag it to the printer again, and it is COPIED into the printer. It makes sense, of course, since moving it to the printer would delete it once it was printed, but it's still eerie. -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe (on a Swedish scale) -- "Anyone who tries to make a distinction between education and entertainment doesn't know the first thing about either" -- Trip Hawkins +++++++++++++++++++++++++++ >From tzs@u.washington.edu (Tim Smith) Date: 7 May 1994 09:46:06 GMT Organization: University of Washington School of Law, Class of '95 Quinn "The Eskimo!" wrote: >>In the thingy that is used to select a color (get it by selecting "other..." >>for your highlight color in the Colors control panel, or double clicking >>on a palette entry in the pattern editor in the General control panel), >>they use a scroll bar to set brightness. I think this violates something >>in the User Interface Guidelines. > >Actually it violates the letter, *but not IMHO the spirit*, of the >guideline that states that you should only put settings, as opposed to >commands, in a popup menu. I was thinking of page 215, where it says that scroll bars are *only* to be used to manipulate the relative position in a document or list. They explicitly say that scroll bars are not to be used where sliders should be used. Thus, the color selector is a blatant violation. --Tim Smith +++++++++++++++++++++++++++ >From hall_j@sat.mot.com (Joseph Hall) Date: Fri, 6 May 1994 17:11:28 GMT Organization: Motorola Inc., Satellite Communications Seems it was dn_crow@bean.open.ac.uk (dn_crow) who said: >An example that has always rather amused me is the one about switching >between applications. The guidlines state that if I click outside any >window belonging to my application, this action should switch me to the >application whose window I have clicked over (e.g. the Finder). The >only action of this click, or indeed double-click, should be to switch >applications. In particular, the guidelines state that the clicks >should *not* be sent to the application being clicked upon. Is this correct? There is one of the finder flags (the application bits you can change with ResEdit) that can be set so that the click will be delivered to the application after it is brought to the front. I have found this a very appropriate behavior in the case of apps like THINK Reference. You click on the "thinker" icon in the background, and wham, there's THINK Reference for you. -- Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users Software Architect | a choice between the easy way and the right way. Gorca Systems Inc. | joseph@joebloe.maple-shade.nj.us (home) (on assignment) | (602) 732-2549 (work) Joseph_Hall-SC052C@email.mot.com +++++++++++++++++++++++++++ >From derek@netcom.com (Derek LeLash) Date: Sat, 7 May 1994 18:07:00 GMT Organization: Corner of Walk & Don't Walk In article johan.solve@itn.hh.se (Johan Solve) writes: > >Metaphors that needs to be explained (as the trashcan in the remove-disk >case) are not good metaphors. Picture a new user who has never seen a Mac >before. He inserts a disk and wants to get it out again. I don't think he >even dare to think of dragging it to the trash. There has to be a Mac guru >around to explain to him that "in this special case, nothing gets deleted. >But the disk will disappear from the desktop (and reappear on the real life >desktop...)" > >Not good. No. The user selects the disk icon and chooses "Put Away" from the File menu. Anything else is an optional short cut. Does the fact that *everyone* drags disks to the Trash *regardless* of how "pure" the metaphor is tell you anything about how the Finder was designed to give users multiple ways to perform an action, so that they can pick the one they want? I guarantee you that five minutes after someone learns that you *can* (not *must*) eject a disk by throwing it in the trash, that will be the only method they ever use. Who cares if the metaphor is perfect? Derek -- Derek LeLash, SrTechWriter/INFP | "Everyone lays off their Prozac for a week BASYS Automation Systems, Inc. | before I come to town. Nothing serious, home: derek@netcom.com | just enough to get a little dip going." work: derek@scooter.amc.dec.com | -- Shawn Colvin +++++++++++++++++++++++++++ >From de19@umail.umd.edu (Dana S Emery) Date: Sat, 07 May 1994 15:54:44 -0500 Organization: Botany, UMCP In article <2qb1lmINNh21@medicine.wustl.edu>, Thomas Reed wrote: > >Dragging items onto a system folder that's not the one you booted with > >doesn't put them in the right place, even if the icons in the folder > >(e.g. apple menu items folder) show correctly. > > Yes, I've often done this. However, there's really only one way for the > computer to know that a folder is the system folder without doing more > stuff than it should have to do -- if it has the active system in it. disagree, the Finder already knows if a viable system is inside, it has to in order to show the proper icon for a system folder. The rest is simply a matter of searching for tagged folders and directing the files, and I, as a user would expect that behaviour to be consistant for any folder showing the blessed system icon, no matter if it was in fact the booted system. -- Dana S Emery +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 8 May 1994 10:09:08 GMT Organization: The Royal Institute of Technology In de19@umail.umd.edu (Dana S Emery) writes: >disagree, the Finder already knows if a viable system is inside, it has to >in order to show the proper icon for a system folder. So far so good. >The rest is simply a matter of searching for tagged folders and directing >the files, and I, as a user would expect that behaviour to be consistant >for any folder showing the blessed system icon, no matter if it was in fact >the booted system. Exactly how would the Swedish Finder know about the names of the Hindu special folders? Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe (on a Swedish scale) -- There's no sex act that can't be made better with Jell-O. +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Mon, 09 May 1994 10:34:31 +0800 Organization: Department of Computer Science, The University of Western Australia In article <2qfo0u$7kn@news.u.washington.edu>, tzs@u.washington.edu (Tim Smith) wrote: >Quinn "The Eskimo!" wrote: >>Someone else wrote: >>>In the thingy that is used to select a color (get it by selecting "other..." >>>for your highlight color in the Colors control panel, or double clicking >>>on a palette entry in the pattern editor in the General control panel), >>>they use a scroll bar to set brightness. I think this violates something >>>in the User Interface Guidelines. >> >>Actually it violates the letter, *but not IMHO the spirit*, of the >>guideline that states that you should only put settings, as opposed to >>commands, in a popup menu. > >I was thinking of page 215, where it says that scroll bars are *only* to >be used to manipulate the relative position in a document or list. True enough. [Whoops, forgot to *read* the post!] I was talking about the "Other..." on the popup menu, not the scroll bars for selecting values. The scroll bars are obviouly broken. btw This "thingy" is called the Colour Picker. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia Repeat 100 times... I will read the post before replying. +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Mon, 09 May 1994 10:56:32 +0800 Organization: Department of Computer Science, The University of Western Australia In article <1994May5.194830.28693@prz.tu-berlin.de>, pcastine@jake.prz.tu-berlin.de (Peter Castine) wrote: >quinn@cs.uwa.edu.au (Quinn "The Eskimo!") writes: >>pcastine@jake.prz.tu-berlin.de (that's me) wrote: >> >>>I think, however, you will be hard-pressed to find >>>a violation in the Finder. >> >>OK, I've got a good one! Why, when you drag a file into a folder where >>there already exists a file of the same name, do you have the option of >>replacing the original. Why doesn't the Finder move it to the Trash??? >>OK, so maybe it's not a *real* HIG violation but it's really inconsistent > >Inconsistent with what? Inconsistent with the fact that every other time you try to delete a file in the Finder you have a chance to undo that action by dragging it out of the Trash. >>and consistency is one of the central precepts of the HIG. > >Consistency is, IMHO, a secondary concern. Smith et.al. discuss the >practical issues of maintaining consistency in real world applications >in their 1982 article "Designing the Star user interface." (Originally >printed in Byte 7(4), reprinted in Baecker & Buxton's _Readings in >Human-Computer Interaction_, the paper is a must-read). Short >precis: consistency is the hobgoblin of small minds. No, *mindless* adherence to consistency is the hobgoblin of small minds. Actually I'd like to know where you precis comes from because my copy of Smitch et al says... %Everyone agrees that consistency is an admirable goal. However, it %is perhaps the single hardest characterist of all to achieve in a %a computer system. In fact, in systems of even moderate complexity, %consistency may not be well defined. The fact that seemingly inconsistent behaviour may be good for the user (eg their classic drog document on printer example, also dragging floppies to the Trash) doesn't imply that you shouldn't evaluate your behaviour in terms of the consistent environment you're creating. Besides the behaviour I advocate (moving replaced files to the Trash) is simply better than the alternative (deleting them). Are you arguing otherwise? If so then you're arguing directly with the HIG, which advocate "Forgiveness" (p10) and says... #You can encourage people to explore your application by building in #forgiveness. Forgiveness means that actions on the computer are #generally reversible. People need to feel that they can try things #without damaging the system; /create safety nets/ for people so that #they feel comfortable learning and using your product. [my italics] >>Question #1 Why does it highlight the window (in both cases)? > >For performance reasons? (Checking privileges might slow down >feedback, direct manipulation. I'm obviously guessing on this one). Personally I think that's crap -- but I don't know enough about AOCE programming to prove it (: >>Question #2 Why does it have different behaviour when it finally realises >> that it's failed? > >What's it supposed to do? Not tell you that it failed? Disregard >privileges? Yeah, but why *2* different behaviours? >>Basically AOCE's HI is severely broken in a lot of places. > >Severely? Well, I'll let that pass before a flame war breaks out. Well I've got some support out there; see the comments by Willie Abrams . -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From howden@munta.cs.mu.OZ.AU (Nicholas James HOWDEN) Date: Mon, 9 May 1994 04:16:44 GMT Organization: Computer Science, University of Melbourne, Australia Paul Ferguson writes: >In article <16674@lhdsy1.lahabra.chevron.com> John V. Blzka, >jjvbl@lhdsy1.lahabra.chevron.com writes: >> Does Apple violate it's own Guidelines in any of it's System 7 >> software? >One classic example that comes to mind is the Alarm Clock, which >suffers from a bunch of violations: non-standard controls, ... >point in their life were mystified to see a flashing alarm clock >where the Apple menu is?) It's hard to find anything about the >alarm clock that doesn't violate the HIG. Another good one is when someone sets the alarm clock, but then removes the item from the apple menu after it goes off. You then have a flashing alarm clock in the apple menu with no way to turn it off (this certainly sounds like a Micro$oft 'feature' to me ;-) Nick. -- - ----------------------------------------------------------------------------- ******** I F Y O U Q U I T , Y O U ' L L N E V E R W I N ******** - ----------------------------------------------------------------------------- +++++++++++++++++++++++++++ >From tzs@u.washington.edu (Tim Smith) Date: 9 May 1994 07:49:53 GMT Organization: University of Washington School of Law, Class of '95 Thomas Reed wrote: >>Dragging items onto a system folder that's not the one you booted with >>doesn't put them in the right place, even if the icons in the folder >>(e.g. apple menu items folder) show correctly. > >Yes, I've often done this. However, there's really only one way for the >computer to know that a folder is the system folder without doing more >stuff than it should have to do -- if it has the active system in it. If >every time you dropped something in a folder, the system had to search >that folder for a copy of the Finder, then all your moves would take a >little longer. Not only that, but it wouldn't be reliable -- sometimes I It would only have to do this when you dropped an extension, control panel, or other magic file into a folder. For most dropping, it doesn't matter if the destination is a System Folder, so it would not have to do more work in the vast majority of cases. --Tim Smith +++++++++++++++++++++++++++ >From dn_crow@bean.open.ac.uk (dn_crow) Date: Mon, 9 May 1994 08:43:17 GMT Organization: (none) In article jmiller@connected.com (James Miller) writes: > In article <1994May5.184300.25982@leeds.ac.uk>, dn_crow@bean.open.ac.uk > (dn_crow) wrote: > > > However, the Finder disregards this: try loading an application and > > bringing it to the front, while still being able to see a finder window > > behind it. If you now click over a visible finder icon, the appropriate > > Finder window is brought to the front (correct) but the icon is > > selected (incorrect). > > The Finder is not really an application in Apple's eyes, it is the user > interface to the system. The reason an icon will stay selected when > another window is brought to the front, is to allow it to more easily copy > files from one window to another. I'm not arguing that Apple is *wrong* to make the Finder work this way: personally, I would like all applications to work like this as I find it very useful. OTOH, I can also see why you don't want to do this: there are some applications where I need to see the whole window before deciding where I click on it, and having to click on the window border to bring it to the front would be a pain. Sigh. An insoluable problem, probably. However right Apple may be in their decision, they are still inconsitent with their own HIGs (which apply to the User Interface of the whole system: Finder and applications alike). Dan +++++++++++++++++++++++++++ >From leblonk@netcom.com (Marcel Blonk) Date: Mon, 9 May 1994 09:51:40 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Maybe this should come under the header of "Apple's blatant disregard for User Opinions" In this thread there have been many complaints about the AOCE UI. Not at all unwaranted IMO. My $.02 on this: before AOCE was released, it was shown a couple of times on the WWDC. I, and many others that I've talked to, always found that the interface needed *major* changes (desktop clutter/finderlookalikebutnotthesameafterall type things). These concerns were often voiced, in the different AOCE forums and workgroups. To apple in general and to the development team in particular. Yet, it was released with all the same UI problems that people (in this case, developers mostly) complained about. What up with that???? To me it seems that Apple has entered a stage, in which the big company mentality is slowly creeping in, in which each little department has it's own little territory to defend and defend it they shall, against every one who'd dare challenge them on their terrain (just one example: how come something like AppendDITL is part of the comm toolbox! It's a generic routine, that has NOTHING to do with communications. If the CTB group wanted this routine to be added, it should have been added in a generic place, NOT the CTB toolbox. What if the already poorly supported CTB becomes extinct or replaced by something better? Would the system still have to support CTB just for the xxxDITL routines (which probably are being used by programs that have nothing to do with the CTB, since they are documented as dialog manager extensions)). We see it all the time, different systems extensions are released, and each uses its own ( different) interface philosophy. There is no consistancy between them anymore. In several workgroup discussions at the WWDC, I found that the teams showed a certain resistance to remarks coming from the developers like: "wouldn't it be better to combine/make consistant/integrate x with y" where x was developed by a different group than y (again, the AOCE group showed this quite distinctively). Is this the end of the Apple we once knew and loved? Is Apple after all, just another company grown big, rigid and more guided by internal politics than by the drive for a better product? I don't know, but that is what I fear is happening. Oops, guess I dropped a few cents more then I was planning to. mb +++++++++++++++++++++++++++ >From resnick@cogsci.uiuc.edu (Pete Resnick) Date: Mon, 09 May 1994 11:15:33 -0500 Organization: University of Illinois at Urbana-Champaign In article , u9119523@sys.uea.ac.uk (Graham Cox) wrote: >Here's a trivial example- not in the system but in most graphics programs, >including MacDraw and ClarisWorks- the guidelines say that the cursor keys >should never be used to position graphic elements, but most programs do >this. That's simply false. From the Macintosh Human Interface Guidlines, chapter 10: In a graphics application, the arrow keys can be used for fine movement of selected objects, particularly since graphics applications typically have no insertion point. If a graphics application uses arrow keys, it should be only to move the selected object by the smallest possible increment (one pixel or one grid unit). For example, the user could select an object and use the arrow keys to move one pixel per keystroke in the direction of the arrow key pressed. pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@cogsci.uiuc.edu +++++++++++++++++++++++++++ >From resnick@cogsci.uiuc.edu (Pete Resnick) Date: Mon, 09 May 1994 11:23:16 -0500 Organization: University of Illinois at Urbana-Champaign In article <2qido4$8c4@news.kth.se>, d88-jwa@dront.nada.kth.se (Jon Wätte) wrote: >In de19@umail.umd.edu (Dana S Emery) writes: > >>disagree, the Finder already knows if a viable system is inside, it has to >>in order to show the proper icon for a system folder. > >So far so good. > >>The rest is simply a matter of searching for tagged folders and directing >>the files, and I, as a user would expect that behaviour to be consistant >>for any folder showing the blessed system icon, no matter if it was in fact >>the booted system. > >Exactly how would the Swedish Finder know about the names of the >Hindu special folders? The same way it knows what the names of the Swedish special folders are: GetResource('fld#', 0); pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@cogsci.uiuc.edu +++++++++++++++++++++++++++ >From jfw@ksr.com (John F. Woods) Date: 9 May 1994 20:36:43 GMT Organization: Kendall Square Research johan.solve@itn.hh.se (Johan Solve) writes: >etaphors that needs to be explained (as the trashcan in the remove-disk before. He inserts a disk and wants to get it out again. I don't think he around to explain to him that "in this special case, nothing gets deleted. desktop...)" Let's remember how this came about. Originally you ejected disks by selecting Eject from the menu (or typing command-E); this left a ghost image that had to be thrown away. A lot of people asked for a short cut, and the obvious one was the one chosen. Of course, if you don't KNOW what it's a shortcut for, it does seem to mean something else. On the other hand, if you had an Ejector on the desktop, what would it mean to drag an ordinary file onto it? +++++++++++++++++++++++++++ >From maynard@elwing.otago.ac.nz (Maynard James Handley) Date: Mon, 9 May 1994 22:49:13 GMT Organization: University of Otago Tim Smith (tzs@u.washington.edu) wrote: > Quinn "The Eskimo!" wrote: > >>In the thingy that is used to select a color (get it by selecting "other..." > >>for your highlight color in the Colors control panel, or double clicking > >>on a palette entry in the pattern editor in the General control panel), > >>they use a scroll bar to set brightness. I think this violates something > >>in the User Interface Guidelines. > > > >Actually it violates the letter, *but not IMHO the spirit*, of the > >guideline that states that you should only put settings, as opposed to > >commands, in a popup menu. > I was thinking of page 215, where it says that scroll bars are *only* to > be used to manipulate the relative position in a document or list. They > explicitly say that scroll bars are not to be used where sliders should > be used. Thus, the color selector is a blatant violation. > --Tim Smith I just want to add two point. Firstly, this use of a scroll bar to select the color may seem a minor matter, but I have found it really irritating over and over. It should be fixed by Apple even if it seems silly. Secondly, Apple have been really dumb by not releasing the slider CDEF inti the system, like they did with the PopupMenu CDEF. If they added this to the system so that programmers could trivially access and use it, problems like this would go away. Maynard Handley +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Tue, 10 May 1994 11:23:03 +0800 Organization: Department of Computer Science, The University of Western Australia In article , leblonk@netcom.com (Marcel Blonk) wrote: >Is this the end of the Apple we once knew and loved? Is Apple after all, >just another company grown big, rigid and more guided by internal politics >than by the drive for a better product? I thought "guided by internal politics" *was* the Apple we once knew and loved (: -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From rmah@panix.com (Robert S. Mah) Date: Tue, 10 May 1994 01:48:31 -0500 Organization: One Step Beyond maynard@elwing.otago.ac.nz (Maynard James Handley) wrote: > Secondly, Apple have been really dumb by not releasing the slider CDEF > into the system, like they did with the PopupMenu CDEF. If they added > this to the system so that programmers could trivially access and use > it, problems like this would go away. Agreed. Also why were the little up/down arrow thingies never rolled into the system? I guess we'll never know... Also, I never did quite understand why both push buttons, radio buttons, check boxes and scroll bars were all rolled into one CDEF. If _I_ were designing things, I would have put buttons into 1, radio buttons and check boxes in another and scroll bars in a third. Good thing they didn't let me do this :-). Cheers, Rob ___________________________________________________________________________ Robert S. Mah -=- One Step Beyond -=- 212-947-6507 -=- rmah@panix.com +++++++++++++++++++++++++++ >From deguzman@binkley.math.uiuc.edu (Alan DeGuzman) Date: 10 May 1994 07:21:34 GMT Organization: Calculus&Mathematica at UIUC jfw@ksr.com (John F. Woods) writes: [snip] >On the other hand, if you had an Ejector on the desktop, what would it mean to >drag an ordinary file onto it? Nothing. If this Ejector was written only to eject volumes, the Ejector's icon would not darken if a file was dragged onto it. -- Alan A. DeGuzman "The problem with the future is that it Calculus&Mathematica keeps turning into the present." DISCLAIMER: "The University can't afford my opinions." - Calvin to Hobbes +++++++++++++++++++++++++++ >From Greg_Marriott@genmagic.com (Greg Marriott) Date: Tue, 10 May 1994 09:09:44 -0800 Organization: General Magic, Inc. rmah@panix.com (Robert S. Mah) wrote: > Also, I never did quite understand why both push buttons, radio buttons, > check boxes and scroll bars were all rolled into one CDEF. They weren't. Buttons are in one CDEF and the scrollbar is in another. > I would have put buttons into 1, radio buttons and check > boxes in another and scroll bars in a third. Separating the buttons would have been a good idea, but it's not so bad the way it is since there's a bunch of common code that is shared. -- Greg Marriott Just Some Guy General Magic, Inc. Disclaimer: My opinions are not necessarily the same as General Magic's. (can a company even HAVE an opinion?) +++++++++++++++++++++++++++ >From Jens Alfke Date: Tue, 10 May 1994 17:47:24 GMT Organization: Apple Computer Thomas Reed, reed@medicine.wustl.edu writes: > Yes, it's true that there has to be "something to be gotten", but I think > most applications these days, background or not, call WaitNextEvent, so > they can control directly how much time they get by giving different > numbers for the sleep value. Yes, but if the front app is calling WNE with a very small sleep time -- like zero -- then there will be much less time for bg apps to run unless they do something evil like running for several seconds at a time without calling WNE. The foreground app should always use a sleep time of infinity unless it needs to be doing something periodically like blink an i-beam or check for modifier key changes, and even then it should sleep at least 15 ticks or so at a time (depending on GetCaretTime, of course.) That said, does the Finder really call WNE with a zero sleep time? I'd be surprised if it did. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From Jens Alfke Date: Tue, 10 May 1994 18:17:22 GMT Organization: Apple Computer Paul Ferguson, pferguson@kaleida.com writes: > On the other hand, what the > slider is doing is changing the brightness from 0-65535, which > is exactly what the example shown on that page says is an incorrect > use of a scroll bar. That's the old color picker. If you install ColorSync you get the New & Improved, All Singing All Dancing color picker, which is much, much nicer and features sliders instead of scrollbars. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik) Date: 10 May 1994 22:11:36 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) In article rmah@panix.com (Robert S. Mah) writes: > Also, I never did quite understand why both push buttons, radio buttons, > check boxes and scroll bars were all rolled into one CDEF. If _I_ were > designing things, I would have put buttons into 1, radio buttons and check > boxes in another and scroll bars in a third. Good thing they didn't let > me do this :-). push buttons, check boxes and radio buttons are in one CDEF (CDEF 0, with variation codes of 0, 1 and 2, respectively) scrollbars are in a separate CDEF (CDEF 1) -gary j kacmarcik platypus@cirrus.som.cwru.edu +++++++++++++++++++++++++++ >From rmah@panix.com (Robert S. Mah) Date: Tue, 10 May 1994 19:10:18 -0500 Organization: One Step Beyond Greg_Marriott@genmagic.com (Greg Marriott) wrote: > rmah@panix.com (Robert S. Mah) wrote: > > > Also, I never did quite understand why both push buttons, radio buttons, > > check boxes and scroll bars were all rolled into one CDEF. > > They weren't. Buttons are in one CDEF and the scrollbar is in another. Woops! You are quite right. I don't know why I thought that until you pointed out the error of my ways... > > I would have put buttons into 1, radio buttons and check > > boxes in another and scroll bars in a third. > > Separating the buttons would have been a good idea, but it's not so bad > the way it is since there's a bunch of common code that is shared. Yes, I understand that many compromises had to be made to fit the original Mac OS into a scant 64K of ROM and 128K of RAM. That they did it was a marvel. Cheers, Rob ___________________________________________________________________________ Robert S. Mah -=- One Step Beyond -=- 212-947-6507 -=- rmah@panix.com +++++++++++++++++++++++++++ >From DACRXL01.OURX124@tcp30.dx.deere.com (Juan Ingles) Date: Wed, 11 May 1994 15:28:57 GMT Organization: Proteus Ventures, Inc. In article <2qkpv1$e9o@news.u.washington.edu> tzs@u.washington.edu (Tim Smith) writes: > It would only have to do this when you dropped an extension, control panel, > or other magic file into a folder. For most dropping, it doesn't matter > if the destination is a System Folder, so it would not have to do more > work in the vast majority of cases. > > --Tim Smith Yes it would: It would have to check every single file to see if it was an extension, control panel, or other magic file. Juan Ingles -- Proteus Ventures, Inc. - Computer Software Consulting and Development 1514 Oriole Ave * Waterloo, IA 50701 * (319) 232-0985 +++++++++++++++++++++++++++ >From mbishop@pliny.ccs.itd.umich.edu (Michael J. Bishop) Date: 11 May 1994 18:00:02 GMT Organization: University of Michigan John F. Woods (jfw@ksr.com) wrote: : johan.solve@itn.hh.se (Johan Solve) writes: : >etaphors that needs to be explained (as the trashcan in the remove-disk : before. He inserts a disk and wants to get it out again. I don't think he : around to explain to him that "in this special case, nothing gets deleted. : desktop...)" : Let's remember how this came about. Originally you ejected disks by selecting : Eject from the menu (or typing command-E); this left a ghost image that had : to be thrown away. A lot of people asked for a short cut, and the obvious one : was the one chosen. Of course, if you don't KNOW what it's a shortcut for, : it does seem to mean something else. : On the other hand, if you had an Ejector on the desktop, what would it mean to : drag an ordinary file onto it? Here's what I think Apple should do. Let me know if you think it is good or bad. -- after I installed the Hardware system update on my powerbook, when I hit the power button, it performed the same command as if I had selected "Shut Down". It's the old "hardware/software integration" genius that Apple is famous for. Why don't they do this for the disk drive? Why don't they make a button that when pushed performs the same command as if the user selected "Put Away" from the File menu? People expect there to be an eject button like on a PC. Putting a button which triggers the software is the best compromise, I believe because it still allows Apple to do that cool hardware integration stuff but is still intuitive to the user. I personally *hate* having to select Shut Down to turn of my mac so the Hardware update was genius and much needed IMO. -- _____________________________________________________________________________ Michael Bishop "The best way to predict the future is to invent it." mbishop@umich.edu - Alan Kay +++++++++++++++++++++++++++ >From Ron_Hunsinger@bmug.org (Ron Hunsinger) Date: Wed, 11 May 94 06:26:41 PST Organization: Berkeley Macintosh Users Group To: resnick@cogsci.uiuc.edu (Pete Resnick),UUCP >In article <2qido4$8c4@news.kth.se>, d88-jwa@dront.nada.kth.se (Jon Wdtte) >wrote: > >>Exactly how would the Swedish Finder know about the names of the >>Hindu special folders? > >The same way it knows what the names of the Swedish special folders are: > > GetResource('fld#', 0); > Wouldn't work. This would only tell the Swedish Finder the names of the *Swedish* special folders. Although... If Apple was hard-pressed, I suppose the active Finder could look in the boot blocks of the other System Folder's volume to get the name of the other Finder, then open the other Finder's resource fork and get the folder names from it. And do all this only if the destination folder matches the id of the blessed folder (available from vcbFndrInfo). Might actually be doable in reasonable time, because you would only have to open the other Finder if you actually had files to disburse into special folders. >pr >-- >Pete Resnick (...so what is a mojo, and why would one be rising?) According to "The Official Scrabble Players Dictionary (Second Edition)": MOJO n, pl. -JOS or -JOES, a magic charm. I believe this is New Orleans slang, possibly of Cajun origin. In any event, "Mr. Mojo Risin" is an anagram for "Jim Morrison". Just so you'll know... -Ron Hunsinger +++++++++++++++++++++++++++ >From ruhl@du.edu (ROBERT A. UHL ) Date: Wed, 11 May 1994 22:04:07 GMT Organization: University of Denver In article <2qarlc$e1n@vixen.cso.uiuc.edu> aad@uiuc.edu writes: >alister@netcom.com (Rick Reynolds aka GreenGoo) writes: > >>>How 'bout dragging a disk to the trash to eject it? > > >>I never really thought much about this issue but I think there should >>have been a disk drive icon on the desktop, always visable but somehow >>conveying to the user that a disk is inserted. > >Uh, what about the disk's icon? Granted, it can be hidden behind windows, >but I'd rather have what *I* want to stay on top of the desktop layer >rather than some floating icons or whatever. > >>When the user wants >>to change disks they can press an "eject" button on the icon. But alas >>that brings up the problem of having a control (which woule have to be >>smaller then other controls) on a Finder icon. > >Now you're on to something. How about letting every icon that is a volume >have a 'switch' or 'button' drawn on (or near) the icon that let's you >eject the volume (eject in the sense of "Put Away"). It could even be dimmed >out for volumes that can't be "Put Away", like the startup volume. >-- >Alan A. DeGuzman Here's another idea: I've always thought that ejecting the disk should get rid of it; you know, if it's out, I can put it in the box and forget about it. Also, the 'Eject' button in the SF dialogs is not a true (IMO) eject; nothing is more annoying to be flipping through floppies on the SF dialog (which I do a lot) and, when you quit, finding a whole mess of grey floppy icons. So... I propose that 'Eject' take the place of the current 'Put Away', and that the 'spit-out-the-disk-but-keep-it-mounted' action be renamed. Not only would this be helpful in the above mentioned ways, but command-E would truly eject the ?!*% disk. -- - ------------------------------------------------------- | Bob Uhl | Spectre | Christos Anesti! | | U of D | Baron Robert von Raetzin | Alithos Anesti! | - ------------------------------------------------------- +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 12 May 94 17:14:12 +1200 Organization: University of Waikato, Hamilton, New Zealand In article <2qido4$8c4@news.kth.se>, d88-jwa@dront.nada.kth.se (Jon Wätte) writes: > > Exactly how would the Swedish Finder know about the names of the > Hindu special folders? I guess the same way it would know about the Muslim special folders, or the Christian special folders, or the Jewish ones, or the atheist ones. :-) Lawrence (born in a place long influenced by Indian culture) +++++++++++++++++++++++++++ >From pcastine@tubprz.prz.tu-berlin.de (Peter Castine) Date: Thu, 12 May 1994 11:10:49 GMT Organization: PRZ TU-Berlin In article ruhl@du.edu (ROBERT A. UHL ) writes: > >So... I propose that 'Eject' take the place of the current 'Put Away', >and that the 'spit-out-the-disk-but-keep-it-mounted' action be >renamed. Not only would this be helpful in the above mentioned ways, >but command-E would truly eject the ?!*% disk. No, no, no, no. You need the 'spit-out-the-disk-but-keep-it-mounted' feature in order to copy disks on Macs with only one floppy drive (which is surely the vast majority of machines out there). There is NOTHING to be gained by renaming menu commands in 1994. There are people out there who have been happily dragging disks to the trash for over ten years. To quote Tog: "An imporant aspect of consistency was defined by Smith et al. [1983] in this way: 'Consistency asserts that mechanisms should be used in the same way wherever they occur.' I would add, by inference, 'and _when_ever they occur': first release or fifth release." (from "Consistency", in The Art of Human-Computer Interface Design, Addison-Wesley 1990, Tog's emphasis.) We now have in the current system: 1) A menu command (w/ command-key equivalent) for ejecting a disk. 2) A menu command (w/ command-key equivalent) for ejecting AND unmounting a disk. 3) A simple mouse gesture for ejecting AND unmounting a disk. I honestly can *NOT* understand all this bitching about (3) above. If you don't want to drag the disk to the trash, then DON'T DO IT. Hit Command-Y and shut up. (BTW, despite my current .sig, this is one point where there is simply nothing to be gained by negating the principle of consistency.) -- Peter Castine | Con'sis'ten'cy (n., pl. -cies) pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative - -----------------------------| b) hobgoblin of little minds ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) +++++++++++++++++++++++++++ >From gjw2824@hertz.njit.edu (Greg Weston) Date: 12 May 94 05:04:11 GMT Organization: New Jersey Institute of Technology, Newark, New Jersey In article <1994May5.172800.22102@bme.ri.ccf.org>, Chuck Simciak wrote: >I'm not sure if this counts as breaking an interface guideline but it is >very annonying. Say I go to save a file, the StandardPutFile dialog >emerges and I have to navigate several folders to get to my desitination. > The file name field has already been filled with a defualt. Here's the >catch. Upon having navigated the multiple folders to place the file, the >SAVE button is now an OPEN button. I then have to click in the filename >text field to cause the button to CHANGE to SAVE. This "feature" was >introduced in System 7 and has been a source of nuisance ever since. I find it tedious, too. But it is a little easier (I find) to press tab, which toggles between manipulating the list and the field, than to grab the mouse and click. (Since in that situation, I've usually had my hands on the keyboard up til then anyway.) Greg +++++++++++++++++++++++++++ >From gt7344b@prism.gatech.edu (MMMMM MMMMM) Date: 12 May 1994 11:57:20 -0400 Organization: Georgia Institute of Technology In article <1994May12.111049.29637@prz.tu-berlin.de> pcastine@tubprz.prz.tu-berlin.de (Peter Castine) writes: >In article ruhl@du.edu (ROBERT A. UHL ) writes: >I honestly can *NOT* understand all this bitching about (3) above. If >you don't want to drag the disk to the trash, then DON'T DO IT. Hit >Command-Y and shut up. > I think you're forgetting the original point of this thread. Yes, dragging a disk to the trash is quick, easy, and we all do it. But it does violate the Mac HIG. It's unintuitive. And I'm willing to admit that I was terrified the first time I tried dragging a floppy to the trash. -- /////////\ /////////\ /////////\ /////////\ /////////\ \_____// / //\____// / //\____// / //\____// / //\____// / ///////// / ///////// / ///////// / ///////// / /////////\ \_______\/ \_______\/ \_______\/ \_______\/ \_______\/ +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 12 May 1994 08:54:10 -0700 Organization: SRI International, Menlo Park, CA In article <1994May12.111049.29637@prz.tu-berlin.de> pcastine@tubprz.prz.tu-berlin.de (Peter Castine) writes: >No, no, no, no. > >You need the 'spit-out-the-disk-but-keep-it-mounted' feature in order >to copy disks on Macs with only one floppy drive (which is surely >the vast majority of machines out there). nah, what we need to implement is Andy Herzfeld (sp?) velocity feature. Pick up a disk icon with the mouse and throw it off the desktop to eject it. :-) The disk icon would then glide across the desktop and when it the icon was completly off the desktop, it would eject. Kind of like when a disk falls off your desk. If you didn't throw it hard enough it would glide to a halt some where on your desktop. Ejecting a disk should be fun! Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From sbb@panix.com (Steve Baumgarten) Date: 12 May 94 12:51:39 Organization: PANIX Public Access Unix, NYC In article <2qtjl0$ob9@acme.gatech.edu> gt7344b@prism.gatech.edu (MMMMM MMMMM) writes: I think you're forgetting the original point of this thread. Yes, dragging a disk to the trash is quick, easy, and we all do it. But it does violate the Mac HIG. No it doesn't. It's a shortcut you don't have to use. Try selecting "Put Away" from the menu; or select "Eject", and then with the disk in your hand you should have no fear of dragging the dimmed icon to the trash. It's unintuitive. And I'm willing to admit that I was terrified the first time I tried dragging a floppy to the trash. Should have tried using the menus first; that's what they're there for. If it were the Mac's sole means of ejecting a floppy, then yes, I'd agree that it's not intuitive. But a menu choice labeled "Eject" is pretty intuitive, you have to admit... -- Steve Baumgarten | "New York... when civilization falls apart, PANIX, New York, NY | remember, we were way ahead of you." | Email: sbb@panix.com | - David Letterman +++++++++++++++++++++++++++ >From pcastine@tubprz.prz.tu-berlin.de (Peter Castine) Date: Thu, 12 May 1994 17:11:36 GMT Organization: PRZ TU-Berlin gt7344b@prism.gatech.edu (MMMMM MMMMM) writes: > >pcastine@tubprz.prz.tu-berlin.de (Peter Castine) writes: >>I honestly can *NOT* understand all this bitching about (3) above. If >>you don't want to drag the disk to the trash, then DON'T DO IT. Hit >>Command-Y and shut up. >> > >I think you're forgetting the original point of this thread. Yes, >dragging a disk to the trash is quick, easy, and we all do it. But it >does violate the Mac HIG. No it doesn't. It's an extension of the Finder's interface. Take a look at HIG p. 38 ('When to go beyond the guidelines'): There are times when the standard user interface doesn't cover the needs of your application. This is true in the following situations: o Your are creating a new feature for which no element or behavior exists. In this case, you can extend the Macintosh user interface in a prescribed way. o An existing element does almost everything you need it to, but a little modification that improves its functions makes the difference to your application. The drag-disk-to-trash convention is *built on an existing interface convention.* (Cf. HIG p. 39) To repeat: the original method was to Eject (or Command-E) the disk and drag the off-line icon to the trash. >It's unintuitive. And I'm willing to admit that I was terrified the first >time I tried dragging a floppy to the trash. Gee, I dunno. I seem to remember way back in spring of '84 wondering "how do I get rid of this disk?", checking out the menus and finding Eject. Sure, I was a little surprised when the shadow of the disk stayed on the desk, but since there didn't seem to be any other appropriate menu items, I dragged the outline to the trash. A day or two later, I thought "Why not combine the two steps and drag the disk straight to the trash? This is a Mac, before something aweful happens, one of these funny message window thingies is sure to pop up and let me back out." (How many people remember the funny alert icons Apple used back then? Now, *those* were worth changing.) Nowadays, I think a lot of beginners click on that funny question mark thingie at the top right of the screen. Guess what Balloon Help says about the trash? BTW, the adjective should be 'unintuitable'. See _Tog on Interface_. Sorry, I'm getting pedantic. Admittedly, naive Mac users sometimes get nervous when they see me dragging a disk to the trash. When this happens, I also go into teacher mode, do the two-step Eject/Trash Outline procedure, demonstrate the Put Away command, and then show the one-step Trash shortcut. But I'd bet they hit on the idea in a couple of weeks on their own. Wonder which people work out faster--dragging a disk to the trash or the 'xp' trick in vi? -- Peter Castine | Con'sis'ten'cy (n., pl. -cies) pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative - -----------------------------| b) hobgoblin of little minds ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) +++++++++++++++++++++++++++ >From Antoine Paul Brusseau Date: Thu, 12 May 1994 16:34:49 -0400 Organization: Carnegie Mellon, Pittsburgh, PA Excerpts from netnews.comp.sys.mac.programmer: 12-May-94 Re: Apple's blatant disrega.. by Peter Castine@tubprz.prz > Take a look at HIG p. 38 ('When to go beyond the guidelines'): > > There are times when the standard user interface doesn't cover the > needs of your application. This is true in the following situations: > > o Your are creating a new feature for which no element or behavior > exists. In this case, you can extend the Macintosh user interface > in a prescribed way. > > o An existing element does almost everything you need it to, but > a little modification that improves its functions makes the > difference to your application. > >The drag-disk-to-trash convention is *built on an existing interface >convention.* (Cf. HIG p. 39) To repeat: the original method was to Eject >(or Command-E) the disk and drag the off-line icon to the trash. If Apple had added a close box to disk icons, people wouldn't be declaring this a violation of HIG. The problem is, the trash icons most common analogy is that of a place one puts items in order to *PERMANENTLY DESTROY THEM*. Putting a disk in the trash, does not do this. This violates peoples expectations. Thus, it is a poor UI design decision. Whereas, a close box is used to remove an item from the desktop. Putting a close box on disk icons would have built on an existing interface convention without violating any preexisting ones (I think:). Tony +++++++++++++++++++++++++++ >From Stephen Jonke Date: 12 May 1994 22:09:24 GMT Organization: NASA GSFC Sorry if this is a repeat, but you can use "Put Away" (Command-Y) in the "File" menu to unmount a disk. I can't remember when this capabilit was added to Put Away - some version of System 7 in any case. This concept is somewhat intuitive, except that "Eject Disk" seems like it should do this and it draws the users attention. My sister has been using Eject Disk when she wants to just get the disk out and I can understand why as this seems the intuitive thing to do. Does anyone every use "Eject Disk" in its current form intentionally any more? Seems like the simple solution is to change it's functionality so that it unmounts the disk without leaving the ghost icon on the desktop, as one would expect. Keep the drag to trash alternative since lots of Mac users are use to that. And then have it so that if you select a floppy disk and pick "Duplicate" it does the floppy copying shennanigans. Doesn't this make a heck of a lot more sense? Steve - ------------------- jonke@gsfc.nasa.gov - ------------------- +++++++++++++++++++++++++++ >From pcastine@tubprz.prz.tu-berlin.de (Peter Castine) Date: Fri, 13 May 1994 08:38:56 GMT Organization: PRZ TU-Berlin mbishop@pliny.ccs.itd.umich.edu (Michael J. Bishop) writes: > >Here's what I think Apple should do. Let me know if you think it is good >or bad. > >-- after I installed the Hardware system update on my powerbook, when I >hit the power button, it performed the same command as if I had selected >"Shut Down". It's the old "hardware/software integration" genius that >Apple is famous for. > >Why don't they do this for the disk drive? Why don't they make a button >that when pushed performs the same command as if the user selected "Put >Away" from the File menu? > >People expect there to be an eject button like on a PC. Putting a button >which triggers the software is the best compromise, I believe because it >still allows Apple to do that cool hardware integration stuff but is >still intuitive to the user. There is a question of cost. Anyone care to estimate what that would add to the price of a Mac? A simple mechanical switch isn't going to do the trick, you need something that will send a signal to the logic board, etc. And don't forget that adding, say $5, to manufacturing costs means a three digit price increse for the consumer. Still, it's not a bad idea. But see my next comment. >I personally *hate* having to select Shut Down to turn of my mac so the >Hardware update was genius and much needed IMO. Using the power switch as a shortcut for Shut Down makes sense on a PowerBook for two reasons: 1) the switch already has the necessary connections to the logic board (you couldn't do this on an SE, where the power switch simply cuts of the power supply) and 2) you can normally reach the switch on a PB without any inconvenience. Many Quadra and Mac II boxes are stuck under a desk (and with them the diskette drives)--in this configuration, menu commands are considerably more convenient. And, although I use the PowerKey extension so I can drop into MacsBugs from the keyboard, I don't really want to have the Shut Down command anywhere on my keyboard--too easy to hit by accident (of course, some people *do* map some key combinations to the Shut Down command... and one of them wrote an extension so that Shut Down produces an Alert "Do you really want to shut down now?" because he hit the key combination by accident too often. This is progress :-? ) I'm not sure if it's possible for an extension to catch the signal sent by the power switch on the Mac II family and cause it to initiate the Shut Down sequence. Now that the subject has been on the net, I expect somebody will try. ;-) -- Peter Castine | Con'sis'ten'cy (n., pl. -cies) pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative - -----------------------------| b) hobgoblin of little minds ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) +++++++++++++++++++++++++++ >From pcastine@tubprz.prz.tu-berlin.de (Peter Castine) Date: Fri, 13 May 1994 09:07:26 GMT Organization: PRZ TU-Berlin Antoine Paul Brusseau writes: > > If Apple had added a close box to disk icons, people wouldn't be >declaring this a violation of HIG. The problem is, the trash icons most >common analogy is that of a place one puts items in order to >*PERMANENTLY DESTROY THEM*. *NO IT DOES NOT*. Drag some files to the trash. See the trash can get fat. Open the trash. There are your files. Select a file. Use the Put Away command. Hey, presto-the file is back where it came from. Drag another file onto the desktop. There it is--this is not permanent destruction. This is a Mac, not an Atari. Selecting "Empty Trash" permanently destroys the file (well, for most users it's close enough to destruction). You also get an alert warning you of this (just like HIG advises). > Putting a disk in the trash, does not do >this. This violates peoples expectations. Thus, it is a poor UI design >decision. Whereas, a close box is used to remove an item from the >desktop. Putting a close box on disk icons would have built on an >existing interface convention without violating any preexisting ones (I >think:). A disk icon is a fairly small object. 32x32 pixels. A close box is also a small object. 10x10 pixels. That's 10% of a disk icon. 10% is actually a lot (particularly nowadays, with custom disk icons that have rockets shooting out of them). [As a footnote, Fitt's law would indicate that it takes about three times as long to move the mouse to a close box as it does to move the mouse to grab a disk icon for dragging. Someone want to do a comparison of these two alternatives for un-mounting a disk a la Card et.al.'s _The Psychology of Human-Computer Interaction_?] I'm not saying that the suggestion to add a close box is a bad one. However, I think it needs to be thought through more thoroughly. -- Peter Castine | Con'sis'ten'cy (n., pl. -cies) pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative - -----------------------------| b) hobgoblin of little minds ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) +++++++++++++++++++++++++++ >From pcastine@tubprz.prz.tu-berlin.de (Peter Castine) Date: Fri, 13 May 1994 09:28:02 GMT Organization: PRZ TU-Berlin Stephen Jonke writes: >Sorry if this is a repeat, but you can use "Put Away" (Command-Y) in the >"File" menu to unmount a disk. I can't remember when this capabilit was >added to Put Away - some version of System 7 in any case. 7.0d1, if I'm not mistaken. As far as users are concerned, since day 1 A.S. (anno septimum, or whatever the Latin would be :) > This concept >is somewhat intuitive, except that "Eject Disk" seems like it should do >this and it draws the users attention. My sister has been using Eject >Disk when she wants to just get the disk out and I can understand why as >this seems the intuitive thing to do. Does anyone every use "Eject Disk" >in its current form intentionally any more? Yes!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Constantly. > Seems like the simple >solution is to change it's functionality No. Changing functionality of commands between software versions is one of the worst possible violations of human interface design concievable. Think about it--what would happen if Ford swapped the position of the emergency brake and the gear shift. Or, if you're using automatic transmission, how about swapping the gas pedal and the brake. Think about it--do you really want to have to check the system software version every time you sit down at a new Mac so that you know which command configuration you've got? >so that it unmounts the disk >without leaving the ghost icon on the desktop, as one would expect. Keep >the drag to trash alternative since lots of Mac users are use to that. >And then have it so that if you select a floppy disk and pick "Duplicate" >it does the floppy copying shennanigans. Doesn't this make a heck of a >lot more sense?a System 8 might extend Duplicate to copying disks. I rather expect not, since the current trend in the interface is towards enhanced use of mouse gestures (there will be less Cut/COpy/Paste as drag-and-drop is implemented in more and more applications). In fact, the mouse gesture for copying disks was one of the earliest implementations of drag-and-drop on Macintosh. -- Peter Castine | Con'sis'ten'cy (n., pl. -cies) pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative - -----------------------------| b) hobgoblin of little minds ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) +++++++++++++++++++++++++++ >From D.A.G.Gillies@bradford.ac.uk (David Gillies) Date: Fri, 13 May 1994 12:25:46 GMT Organization: Unseen University, Ankh-Morpork In article ruhl@du.edu (ROBERT A. UHL ) writes: >Here's another idea: >I've always thought that ejecting the disk should get rid of it; you >know, if it's out, I can put it in the box and forget about it. Also, >the 'Eject' button in the SF dialogs is not a true (IMO) eject; >nothing is more annoying to be flipping through floppies on the SF >dialog (which I do a lot) and, when you quit, finding a whole mess of >grey floppy icons. >So... I propose that 'Eject' take the place of the current 'Put Away', >and that the 'spit-out-the-disk-but-keep-it-mounted' action be >renamed. Not only would this be helpful in the above mentioned ways, >but command-E would truly eject the ?!*% disk. > Of course 'Eject' ejects the disk. It enables you to remove it from the disk drive, doesn't it? That fits any reasonable definiton of eject in my book. It takes most people with an IQ higher than that of a potato to realise the difference between 'Eject', and 'Put Away'. For those amongst us who are not completely illiterate, the distinction is also pointed out in *the manual* (you know, that big thick ring-bound thing that is put on one side by MacBozos and never read, thereby generating 98% of tech support traffic, and giving rise to those 'Tricks'n'Tips' columns in magazines, full of things like "did you know that if you hold down the option key when opening a folder, the parent folder will disappear?") Changing the way this works now would only serve to confuse the people who extracted their heads from their arses long enough to actually understand how to use a Mac. Keeping volumes mounted is a time-saving feature. If you had to wait the twenty seconds or so it takes to mount a floppy every time you popped one out of the slot in the Standard File dialog, you'd go mad. It's not perfect, but until someone comes up with abetter solution we're stuck with it. ______________________________________________________________________ David A. G. Gillies (D.A.G.Gillies@bradford.ac.uk) University of Bradford, Bradford, West Yorkshire, England (c) 1994 Wittgenstein and The Furniture Depository of The Living Dead A little learning is a dangerous thing - but not half as dangerous as a lot of ignorance. - ---------------------REPLIES VIA EMAIL PLEASE----------------------- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ +++++++++++++++++++++++++++ >From D.A.G.Gillies@bradford.ac.uk (David Gillies) Date: Fri, 13 May 1994 12:30:48 GMT Organization: Unseen University, Ankh-Morpork In article <2qtjf2$4us@unix.sri.com> mxmora@unix.sri.com (Matt Mora) writes: >In article <1994May12.111049.29637@prz.tu-berlin.de> pcastine@tubprz.prz.tu-berlin.de (Peter Castine) writes: > >>No, no, no, no. >> >>You need the 'spit-out-the-disk-but-keep-it-mounted' feature in order >>to copy disks on Macs with only one floppy drive (which is surely >>the vast majority of machines out there). > >nah, what we need to implement is Andy Herzfeld (sp?) velocity >feature. Pick up a disk icon with the mouse and throw it off the desktop >to eject it. :-) The disk icon would then glide across the desktop and when it >the icon was completly off the desktop, it would eject. Kind of like when >a disk falls off your desk. > >If you didn't throw it hard enough it would glide to a halt some where on >your desktop. > >Ejecting a disk should be fun! > Great idea! Anyone want to write this? It could be a bit tricky... ______________________________________________________ David A. G. Gillies (D.A.G.Gillies@bradford.ac.uk) (c) 1994 Wittgenstein's Amazing Underwater Supermarket _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ +++++++++++++++++++++++++++ >From Antoine Paul Brusseau Date: Fri, 13 May 1994 09:30:06 -0400 Organization: Carnegie Mellon, Pittsburgh, PA Excerpts from netnews.comp.sys.mac.programmer: 13-May-94 Re: Apple's blatant disrega.. by Peter Castine@tubprz.prz > > If Apple had added a close box to disk icons, people wouldn't be > >declaring this a violation of HIG. The problem is, the trash icons most > >common analogy is that of a place one puts items in order to > >*PERMANENTLY DESTROY THEM*. > > *NO IT DOES NOT*. Drag some files to the trash. See the trash can > get fat. Open the trash. There are your files. Select a file. Use > the Put Away command. Hey, presto-the file is back where it came > from. Drag another file onto the desktop. There it is--this is > not permanent destruction. I think you misread my post. I said "in order to *PERMANENTLY DESTOY THEM*", not "so that they are *IMMEDIATELY DESTROYED*". To further the analogy, if I put an object from my desk into the rubish bin, it is not immediately destroyed. If I choose, I can take the object out any time before the cleaning staff comes. This is the correct analogy, and it is followed consistently with file icons. Putting a floppy disk into the trash in order to eject it does not follow this analogy. This is the point of my previous post. Tony +++++++++++++++++++++++++++ >From dowdy@apple.com (Tom Dowdy) Date: Fri, 13 May 1994 15:40:32 GMT Organization: Apple Computer, Inc. In article , cwiltgen@mcs.com (Charles Wiltgen) wrote: > In article <16674@lhdsy1.lahabra.chevron.com>, > jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) wrote: > > > Hello, > > I've been working on a presentation on Human Factors Engineering. > > I am using Apple's User Interface Guidelines as an example. > > What I would like to know is: > > Does Apple violate it's own Guidelines in any of it's System 7 > > software? > > If so, can I easily demonstrate it? > > How 'bout dragging a disk to the trash to eject it? I'm not sure how this is a direct violation of the UI guidelines (and maybe it is)...It *is* probably a non-intuative feature, that wasn't well thought out for first implementation. However, I'd like to ask you if you now use the "Put Away" menu item in System 7, which performs the same function. Or, do you continue to drag the disk to the trash. If you continue to drag the disk to the trash -- why? If we took away that feature, would you complain? -- Tom Dowdy Internet: dowdy@apple.COM Apple Computer MS:302-3KS UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy 1 Infinite Loop AppleLink: DOWDY1 Cupertino, CA 95014 "The 'Ooh-Ah' Bird is so called because it lays square eggs." +++++++++++++++++++++++++++ >From mbishop@ovid.ccs.itd.umich.edu (Michael J. Bishop) Date: 13 May 1994 16:28:51 GMT Organization: University of Michigan Peter Castine (pcastine@tubprz.prz.tu-berlin.de) wrote: : mbishop@pliny.ccs.itd.umich.edu (Michael J. Bishop) writes: : Anyone care to estimate what that would add to the price of a Mac? : A simple mechanical switch isn't going to do the trick, you need : something that will send a signal to the logic board, etc. : And don't forget that adding, say $5, to manufacturing costs means : a three digit price increse for the consumer. : Still, it's not a bad idea. But see my next comment. : >I personally *hate* having to select Shut Down to turn of my mac so the : >Hardware update was genius and much needed IMO. : Using the power switch as a shortcut for Shut Down makes sense on a : PowerBook for two reasons: 1) the switch already has the necessary : connections to the logic board (you couldn't do this on an SE, where : the power switch simply cuts of the power supply) and 2) you can : normally reach the switch on a PB without any inconvenience. Many : Quadra and Mac II boxes are stuck under a desk (and with them the : diskette drives)--in this configuration, menu commands are considerably : more convenient. And, although I use the PowerKey extension so I : can drop into MacsBugs from the keyboard, I don't really want to : have the Shut Down command anywhere on my keyboard--too easy : to hit by accident (of course, some people *do* map some key : combinations to the Shut Down command... and one of them wrote : an extension so that Shut Down produces an Alert "Do you really : want to shut down now?" because he hit the key combination by : accident too often. This is progress :-? ) Ah ha! I can build on that. The ergonomic keyboard comes with an extension which allows the keyboard to switch the volume up and down. How hard would it be to use one of those "new" keys to eject the disk? Then both the power key and the "put away" key are both accessible from the keyboard. Apple adds new keys all the time that do cool new things. I think they could have added a "put away" key. : -- : Peter Castine | Con'sis'ten'cy (n., pl. -cies) : pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative : -------------------------------| b) hobgoblin of little minds : ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) -- _____________________________________________________________________________ Michael Bishop "The best way to predict the future is to invent it." mbishop@umich.edu - Alan Kay +++++++++++++++++++++++++++ >From mwalker@netcom.com (Mel Walker) Date: Fri, 13 May 1994 16:37:17 GMT Organization: Committee to Elect Dan Quayle Lord of the Cosmos Antoine Paul Brusseau (ab2y+@andrew.cmu.edu) wrote: : If Apple had added a close box to disk icons, people wouldn't be : declaring this a violation of HIG. The problem is, the trash icons most : common analogy is that of a place one puts items in order to : *PERMANENTLY DESTROY THEM*. No, the common analogy is that one puts items into a trash can in order to *GET RID OF THEM*. Thus, when I want to get rid of a disk, I throw it in the trash. I does not violate my expectations in the slightest. : Putting a disk in the trash, does not do : this. This violates peoples expectations. Thus, it is a poor UI design : decision. Whereas, a close box is used to remove an item from the : desktop. Putting a close box on disk icons would have built on an : existing interface convention without violating any preexisting ones (I : think:). What happens when you double-click on the disk to open it, and hit the close box? Since the close box would take a sizeable amount of the disk icon, I figure that it would happen quite a bit. In addition, the close box would interfere with my cool custom icons. :-) Just out of curiousity, are there any GUIs that put close boxes on a disk icon? -- Mel Walker mwalker@netcom.com +++++++++++++++++++++++++++ >From Stephen Jonke Date: 13 May 1994 17:47:43 GMT Organization: NASA GSFC In article <1994May13.092802.16931@prz.tu-berlin.de> Peter Castine, pcastine@tubprz.prz.tu-berlin.de writes: >Changing functionality of commands between software versions >is one of the worst possible violations of human interface design >concievable. Think about it--what would happen if Ford swapped the >position of the emergency brake and the gear shift. Or, if you're >using automatic transmission, how about swapping the gas pedal >and the brake. I disagree with this opinion. You can't compare these two things, because the consequences are quite drastically different. If you do what you suggest with cars, people can be killed. If you do what I suggest with Empty Trash and duplicate, you risk people being annoyed once or twice, then seeing that it's better and being happy with it. That's not much of risk and there is great reward. If lots of people use the current Eject Disk functionality for things other then copying, then they could throw in a new command that does this (offhand I can't think of a name) that is NOT "Eject Disk". You can go overboard with consistency and this is a perfect example. You are being consistent with something that was wrong to start with. That is a greater mistake, IMHO. Plus, Apple's goal these days is to attract NEW Mac users and if there are quirks like the Eject Disk "feature", they are going to pick these out and say "boy, this is stupid, I'm going back to my PC which is just as good" (not that this is true, but we are talking about PC users who are confinced their PCs are just as good! :) Actually, here's another alternative that would be a better, but not as good as my first suggestion. Keep Eject Disk and have it appear to do the same as usual, but make it so that it no longer asks you to put the disk in if you shutdown (or whatever.) Also, you should be able to drag the greyed disk icon to the trash similarly. This is actually the way it use to work anyway, right? Steve - ------------------- jonke@gsfc.nasa.gov - ------------------- +++++++++++++++++++++++++++ >From David Casseres Date: Fri, 13 May 1994 17:46:08 GMT Organization: Apple Computer, Inc. In article Tom Dowdy, dowdy@apple.com writes: > I'm not sure how this is a direct violation of the UI guidelines > (and maybe it is)...It *is* probably a non-intuative feature, > that wasn't well thought out for first implementation. > > However, I'd like to ask you if you now use the "Put Away" menu > item in System 7, which performs the same function. Or, do > you continue to drag the disk to the trash. If you continue > to drag the disk to the trash -- why? If we took away > that feature, would you complain? I bet anything that if we took away that feature there would be howls of rage from so many people that we'd put it right back in as quickly as possible. I was around when this was invented, and I guarantee that everyone knew it was unintuitive, and thought hard about it. But everyone also knew that there really had to be a way to eject a diskette with just a simple mouse gesture, and no one could come up with a better way to do it. There are lots of things about GUI design that simply can't be accounted for in guidelines. For example, when you drag a file from one folder to another, it disappears from its original location and appears in the new location. *Except*... if you are dragging it from one disk to another then it doesn't disappear from the original location. It's completely inconsistent and not even intuitive, but it's *right*. We know this because on the Lisa it worked the other way, and the file was erased from its original disk after being copied to the new one. And this turned out to be *wrong*, even though it was consistent and intuitive. Sometimes even the best guidelines need to be blatantly disregarded. - ----------- David Casseres Exclaimer: Hey! +++++++++++++++++++++++++++ >From resnick@cogsci.uiuc.edu (Pete Resnick) Date: 13 May 1994 18:44:39 GMT Organization: University of Illinois at Urbana Ron_Hunsinger@bmug.org (Ron Hunsinger) writes: >resnick@cogsci.uiuc.edu (Pete Resnick) writes: >>In article <2qido4$8c4@news.kth.se>, d88-jwa@dront.nada.kth.se (Jon Wdtte) >>wrote: >> >>>Exactly how would the Swedish Finder know about the names of the >>>Hindu special folders? >> >>The same way it knows what the names of the Swedish special folders are: >> >> GetResource('fld#', 0); >> >Wouldn't work. This would only tell the Swedish Finder the names of the >*Swedish* special folders. Although... >If Apple was hard-pressed, I suppose the active Finder could look in >the boot blocks of the other System Folder's volume to get the name of >the other Finder, then open the other Finder's resource fork and get the >folder names from it. And do all this only if the destination folder >matches the id of the blessed folder (available from vcbFndrInfo). I think you are getting confused here. The question is, if I drag to a non-blessed system folder, why can't the Finder figure out where to put the files? To realize it's a legitamate (albeit unblessed) system folder in the first place, you must *already* notice that there is a System and a Finder in that folder. You don't need to go looking in boot blocks to figure that out; you simply need to look at file types. Once you discover that there are appropriate System and Finder files using the file types, you can then open the appropriate one (I forget whether the fld# is in the System or the Finder; I believe it's the former) and do the GetResource from that file (I guess using Get1Resource instead of GetResource actually). You won't get the ones from the Swedish system since the Hindu (or whatever) system is the current resource file. It doesn't have to be the blessed folder since any system folder will be reasonable to put things into appropriate places. Right? pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@cogsci.uiuc.edu +++++++++++++++++++++++++++ >From peirce@outpost.SF-Bay.org (Michael Peirce) Date: 13 May 94 00:44:48 GMT Organization: Peirce Software, Inc. In article (comp.sys.mac.advocacy,comp.sys.mac.programmer), zig@wc.novell.com (Zig Zichterman) writes: > One place Apple violates its suggested guidelines in in the Finder's > "About This Macintosh..." menu item. The Mac HI Guidelines book (pages 67-70) > suggests that the ellipsis (...) should appear only on menu items that > require *additional* information before they can complete (such as > choosing a file from an Open... dialog, or setting up options in a > Preferences... dialog, and so on). For menu items that execute without > further information from the user, such as Cut, Copy, showing an About > box, and so on, the ellipsis should not appear. > > After 10 years of tradition, who's going to really remove the ellipsis > from their "About..." menu? I've always interpretted the presence of an ellipsis to mean a dialog will be called up, i.e. something will interupt you focus on the current window. Or more specifically, you'll have to do something to get back to where you were. With this interpretation, the About... is correct. __ Michael Peirce __ peirce@outpost.sf-bay.org __ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301 __ __ San Jose, California USA 95117-1844 __ Makers of: Smoothie & __ voice: +1.408.244.6554 fax: +1.408.244.6882 __ Peirce Print Tools __ AppleLink: peirce & AOL: AFC Peirce +++++++++++++++++++++++++++ >From Antoine Paul Brusseau Date: Fri, 13 May 1994 15:42:40 -0400 Organization: Carnegie Mellon, Pittsburgh, PA Excerpts from netnews.comp.sys.mac.programmer: 13-May-94 Re: Apple's blatant disrega.. by Mel Walker@netcom.com > No, the common analogy is that one puts items into a trash can in order > to *GET RID OF THEM*. Thus, when I want to get rid of a disk, I throw it > in the trash. I does not violate my expectations in the slightest. Unfortunately, the most common consequence of getting rid of something is that it is permanently destroyed (i.e., the trash icon is most often used to destroy files). Thus, the association in many peoples' minds is a place where one puts an item in order to permanently destroy it. The reason I bring this up, is that more than a few people that I've taught to use Apple computers have been shocked that putting a disk in the trash can is the easiest way of ejecting a disk. Several non-technically oriented people I know actively balk at using this feature because they are afraid their data is going to be erased (no matter how many times I reassure them it isn't). Philosophically and empirically, the evidence indicates that this feature is more than a little dubious as a UI shortcut. Since many people including myself make extended use of this feature, it is obviously desirible to have a UI shortcut for ejecting a disk (menus are just too incovenient and command-y is too arcane). That's why I think some other method (that doesn't violate common expectations), such as having a close button on ejectable media volumes or dragging ejectable media icons off the desktop, as a way of ejecting them is preferable. Tony +++++++++++++++++++++++++++ >From Antoine Paul Brusseau Date: Fri, 13 May 1994 15:55:08 -0400 Organization: Carnegie Mellon, Pittsburgh, PA Excerpts from netnews.comp.sys.mac.programmer: 13-May-94 Re: Apple's blatant disrega.. by David Casseres@apple.com > Sometimes even the best guidelines need to be blatantly disregarded. That's by far the best argument I've heard in support of dragging icons into the trash. But what about putting a close box on (or near) floppy icons, or dragging them off the desktop in order to eject them? Both of these methods sound intuitive and consistent (at least superficially). Tony +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 14 May 94 04:04:01 MST Organization: (none) In article , Antoine Paul Brusseau writes: > If Apple had added a close box to disk icons, people wouldn't be > declaring this a violation of HIG. The problem is, the trash icons most > common analogy is that of a place one puts items in order to > *PERMANENTLY DESTROY THEM*. Putting a disk in the trash, does not do > this. This violates peoples expectations. Thus, it is a poor UI design > decision. Whereas, a close box is used to remove an item from the > desktop. Putting a close box on disk icons would have built on an > existing interface convention without violating any preexisting ones (I > think:). > > Tony Now figger out how to make sure that the close box was clicked on and the user wasn't trying to either select or open the file...