NextStep sold hardly at all because the prices of the boxes were even more expensive than the Macs of the era which were already rediculously priced. That and the lack of applications, its focus on students and inability to run current (at the time) Mac applications at the time said more for Next Inc's troubles than the NextStep OS itself.
While I think that NextStep itself played more of a role than you give it credit for, let's discount that for the moment. Now replace 'Next' with 'Apple,' stick Steve at the helm... and I find that unless Apple had made a spectacular effort to turn around, an almost impossible one, that they're repeating some non-technically oriented mistakes of the past as well.
I use Macs all the time, own a G3 BW, been using them since the mid-80's, used to sell and repair them... I think my Mac credentials are in good order, thanks.
I also have a NeXT Cube that I used to use (hm, I could probably sell it now... I need the cash) and I completely agree with you that OS X is OpenStep 6. But I contend that OpenStep was, while a user friendly Unix, not as user friendly as any OS out there. MacOS, BeOS, and even Windows beat it in those regards.
MacOS 8 did not introduce the control strip, and while I agree that spring loaded folders and popup windows (the latter, one of my favorite things) are great innovations, they do kind of pale before the work done earlier. Platinum is a skin, I'm afraid, and that's pretty minor. Of course, Apple laid off a lot of key HCI staff just after System 7 was done, and most of the rest trickled out not awfully long afterwards. They're sitting on a mountain of good UI concepts, but little is being produced. I've been fortunate enough to see little glimpses here and there, though things are often under wraps. Quite a lot of the things that came out in the 90's were in fact developed by third parties!
Sheets are about the best thing I've seen in OS X, I'm afraid.
Anyway, looking like Unix is quite a different thing from behaving like Unix. Behavior, really, is more fundementally important than appearance. (though I'm not discounting the latter) And in that respect, there's not been much improvement AFAICT.
The appeal to other Unix users is probably going to be more minimal than you think. Apple hasn't got the experience or products to move into the medium-high end server market. (hell, you can't even rackmount their stuff easily) And on the low end, you've got to contend with x86 commodity hardware that can be dual booted into Windows if necessary. I'd be a little more encouraged if they migrated to x86, but that's probably not going to happen.
The reason that they must address the existing user base first is simple, really. It's the only one they have. Perhaps Apple can attract other customers. But given the high barriers to entry, regarding incompatable software and expensive niche hardware, and the better/good dichotomy, gambling that new customers can be brought in at the expense of old customers is insane. It's an absolutely ridiculous risk to unecessarily run.
As for UI testing, I really, really doubt that there was much at all. The UI is too unpolished -- it bears the hallmarks of something that was designed by fiat, designed by artists, and not designed by HCI designers. Most UI experts that have weighed in at all have tended to agree, several of whom have worked at Apple.
You remark that the previous UI didn't move many boxes. Well, the commercial success of OS X has, of course, yet to be realized. But are you seriously proposing that regression would work better? DOS sold bajillions of boxes... but I'm not hearing much call for that any more.
NextStep, upon which OS X is clearly based, sold hardly anything at all... I'd give MacOS more credit. Even in the face of MS, it was the only OS with any desktop popularity at all, besides Windows, though Apple squandered it for ages.
While of course, different users will have different preferences, HCI is more of a science than you seem to believe. Objective user testing and creative thinking can in fact determine _just_ how much of an improvement something is for various classes of user.
Given that, based on inclination to go with the Mac platform, prior investments, planned usage, and populations, the order of users whose needs should be addressed, and who should be attracted basically goes: Mac, Windows, newbies, Unix, misc. it's really mysterious as to why, for example, OS X would have Unix-like user directories, or a terminal divorced from the GUI.
Of course, Apple has done little HCI work that is seriously innovative since System 7. So it's not too surprising. Personally, I'm always suspicious when I see some Unix feature that was never in popular use crop up in OS X. It's tough for me to imagine that there could be so little improvement to UI than what was done by two guys in the late 60's.
Were there ideas that were quite cutting edge, that were nicely polished (e.g. directories that refresh themselves, much like System 1's did, hierarchical menus not limited to five levels, etc.) I'd be less critical of their overall efforts, and could concentrate on the substantive nature of the UI itself. Right now, there's not much that's new to go on.
Regarding metadata, there are other ways to handle cross-platform issues that preserve metadata, as well as new features that could be provided by the OS and documented in the HIG, such as auto-appending suffixes to outgoing flat files, etc. Apple's regressing to the old ways, and it's not all that necessary. NTFS has good support for metadata, for allied things like forked files, and is the coming standard. Apple's getting left in the dust, and ironically is NOT being a terribly good neighbor.
UI is better in some respects, but a step down from MacOS, and by no means an improvement to the state of the art.
Security model hasn't changed.
Speed's not amazing, though at least 10.1 is an improvement over the earlier releases.
Metadata's being depreciated.
I'm sorry, I'm not seeing that it's a substantial improvement on Unix, OR that Unix is a particularly desirable choice of OS for ordinary people. (Frankly, they could all stand significant improvement)
Except of course, that this ignores the lessons regarding Unix's abyssymal UI; ignoring the lesson that OS demands on hardware have to be as minimal as possible (esp. wrt the graphics system); ignoring areas where Unix could stand improvement, e.g. security models, filesystems, etc., etc.....
Unix is not the end all be all of OSes. Reimplementing it means that EXACTLY the mistakes of the past will be made, as opposed to a random assortment of mistakes and successes -- including new ones -- by trying something different
Exactly. It is in no way a jurisdictional action, and that is what many, many more networking cases tend to revolve around. Here it is just how zoning law is applied.
The court has merely interpreted the zoning law to be intended to prevent the activities of some defendant from upsetting the activities of some plaintiff. If I opened a piledriver testing facility next to a hospital, that would be in violation of the zoning laws regarding sounds.
If I could _mute_ the piledrivers so that there was absolutely no alteration in the condition of the people at the hospital whether they were on or off, I would not be in violation of that particular law.
That it involves the internet really has nothing significant to do with it
I'm not trolling. I'm saying there is a difference between a user and a users' software, and that further granularity (e.g. barring spyware from accessing system resources like the network, or from being executed, etc.) are desirable. But see the other reply for more.
True -- a user can often work around any security, particularly around the lax amount that is preferred for otherwise optimal working conditions.
But -- It seems fairly unusual that you would need to give any given downloaded executable access to everything across the board. What does Photoshop need with rwx to my mail? Why would I give a calculator program access to the network? I'm simply saying that there should be more granularity. Without the user at the console manually doing it, most programs do not need access to certain reserved files (e.g. for programs not already explicitly trusted by the admin, it's probably safe to forbid writes to.cshrc) or to files of a different type than they create or work with (e.g. textfiles to a graphics editor).
Will this stop all malicious software? No, of course not. But it will further tighten the noose, and provide resources for a user or admin who wants to cut off the air supply to some of that such software. It also at least helps to constrain the amount of damage that parasitic malware can do -- if Outlook were restricted to write access to its own mail files, network connectivity, and the ability to read files that the user at the console had attached, it can screw with your mail, but at least it's not going to wipe out your textfiles.
I'm really not trolling here; it seems to me that once you get through the single layer of security protecting the user, as so many things do, you're giving who knows what the keys to the castle. Further compartmentalization, at least the possibility of it if the user desires it, seems reasonable.
If I took an executable and changed the type/creator codes, it will no longer be recognized as an executable by the system. Rather as though if you stripped a Windows program of the.exe suffix, and tried to run it.
Forked files are actually pretty cool. If you're using the NTFS filesystem on Windows, you have them too! And IIRC Linus wants them to become commonplace on Linux, if only for intercompatability reasons. So you'd probably look into what they actually do do, pretty quick;)
On the plus side the Unixy features of OSX should prevent it from hosing your system, you just have to worry about your documents....
Sounds like a major bug in Unix, to me. It's things like this, that are just assumed to be the way that things are, that really get under my skin. There are, I understand, alternative security models (I'm mostly thinking of capabilities, here) that would eliminate this security hole. But God forbid that Apple actually innovate anymore -- no, it's the NeXT way or the highway.
No. If for example, there were no license at all, the transfer would be entirely legal. The issue is whether the license is binding, or whether the default no-license state is defaulted to.
The use of the thing is not governed by copyright law unless the use is a special one that involves wide dissemination, e.g. public performance.
Specifically with regards to software, the creation of copies necessary in order to operate the software (e.g. copies from CD to HD to RAM) or to back it up, provided that it was otherwise purchased legally, and are not retained if the software is sold or otherwise disposed of, are legal.
But this is largely irrelevant. We're talking contracts. Mostly, we're talking, are the EULAs valid contracts?
Okay look, software is a red herring here. The fact that they're selling you software has absolutely nothing whatsoever to do with anything.
They could be selling you a book, or a car, or anything. Doesn't matter.
And there's no question that it is legal to agree to an explicit contract wherein it is stated that you cannot resell the good that was sold to you via that contract. That's perfectly legal, unless there were something else altogether that could void the contact.
The question is are EULAs, because of the way in which, and the time at, they are presented, legal contracts.
If you went down to the Ford dealership and they sold you a car, and in the glovebox was a slip of paper saying "by driving this car you agree that you cannot resell it" we'd be having the same discussion. Don't get hung up on software. There's nothing terribly special about software in this regard.
Any good could be considered as a service by that line of non-reasoning. (e.g. 'I bought a car' v. 'You bought the right to go places, not a car')
No, the truth of it is that you bought a copy of a work. Rather like a book. And a hundred years ago, it was determined that copyright holders cannot, merely by virtue of their copyright, restrict in any way, people from reselling that work. It's called the First Sale doctrine.
The question really is whether or not the licenses included with software are valid in whole, or in part, and if so, at what time do they become active? It has very, very little to do with software specifically, but rather contract law in general.
Well, I'm basing what I heard about the mouse history on documents at Stanford. The page here is particularly useful, but really there's a whole bunch of them, because it's an interesting subject.
Pang: Can you say something about your role in deciding how many buttons the mouse would have?
Raskin: Yeah. That's my fault entirely.
I had observed at PARC, in myself and others, that the three-button mouse was confusing. And I said, "What would be the way of making it so there would never be any question about what button to press?" If there's only one button, you can't make any mistakes. So I said, "Let's make a mouse with one button." But the first thing is, how can you do all the things? You have to use a few buttons to do everything on the PARC machine.
So I designed the method of using a one-button mouse, and so invented a lot of methods that are still in use, like click and drag for selecting a region, and for dragging things across the screen. Now the first one, it turns out, I only learned years later-- only a few years ago-- there had been a use of dragging for selecting text in Gypsy, but I didn't know about that editor then, so I invented it independently. But the ones about collecting things, and dragging icons across, that was not at PARC.
So I invented the one-button mouse, and the methods for how to use it, and it's really a very heady feeling to go up to almost anybody in this entire culture, and know that they're using something that I invented every day. They don't know that anybody invented it at all.
and then there's this, by some of the designers who built the mice themselves:
Sun: The only story I have on that is also anecdotal. Someone else told me that Chris Espinosa said that it would be easier for him to write the documentation if there was only one button, so he wouldn't have to talk about "left button" and "right button."
Kelley: The woman who was writing the user's manual was heavily involved, and they thought that it would be easier to explain how to use it if it had one button.
Yurchenco: I don't remember strong arguments for two buttons from anybody. I don't think there was much strong support from it at Apple at all. There may have been some software guys who wanted it because they could put more bells and whistled on, but I don't ever remember any screaming arguments there. I don't think it was a big decision in the end.... It's probably one of those osmosis decisions: the consensus is there, and people just say, "Yeah, it's going to be one button."
Sachs: As for the one-, two-, or three-button design, we just built all kinds of different prototypes of buttons, and one button seemed easier to use. It might have gone differently if there was software to use that would have shown why you needed a second button. At Apple, the evidence that the mouse was designed first, rather than the user interface, is that only later on did the idea of option-clicking, shift-clicking, command-clicking come about. If we had known that that was required, it might have forced us to make a two-button mouse.
So it appears that the one-button mouse was developed by Raskin, and supported by a few people, around whom a consensus naturally grew, _prior_ to the full-fledged design or testing of the UI at all, and founded on little more than Raskin's personal experiences with Alto mice. There may have been after-the-fact user testing, but no one has seemed to discuss this. As I am very interested in computing history, I would be very grateful if you could point me to someplace that contraverts this point, and which has some weight behind it. (honestly, it's interesting to me, no joke)
As for the early Mac interface, remember, an intuitive UI is one that people can pick up immediately. An easy-to-learn UI is one that requires actual effort to learn, but very very little. Given that the Mac had to ship with really good documentation (I still have copies), audio casette tapes, posters, etc. back in '84 and still people often had a hard time 'getting it' (e.g. the disasterous Test Drive promotion) I wouldn't call it intuitive, so much as very easy to learn. There is a minor, but important difference, i.e. if a mouse was intuitive, people would know what to do with it the first time they see it, rather than learning how to use it easily by watching someone use it for all of five seconds.
No, the ergonomic advantage of some of the good Mac mice -- I'm thinking of the ADB II mouse and the USB Pro mouse, here -- are that several fingers are engaged in depressing the button. This reduces strain on any particular finger either in relative frequency, or in amount of exertion necessary.
I _really_ like the ability to adjust the resistance of the USB Pro mouse in fact. That's another must-have feature.
I'm thinking of something approximately the size and shape of the ADB II mouse, or the blue, optical Logitech Wheel mouse. Let's leave out the thumb jog for the moment -- I'm still hashing that out, and it might indeed be something that can't be tackled on a symmetrical mouse while still retaining economy. The entire forwards section of the mouse, from the bump to the tail would be the main button. No matter which hand you operated it with, there would only be a single primary. The secondary buttons would probably be small flush buttons in a position to be depressed by the fingertip of the first finger (one for the left, one for the right) if rolled slightly away from the primary button.
I don't like the left/right button dichotomy. I prefer primary/secondary, and that's easily reinforced through size. The 2d button for the wrong hand of course, whichever that happens to be, probably winds up being a useless tertiary both in terms of functionality and ergonomics, but this isn't something I delve into a whole lot.
Plus I'm a rightie, so in a pinch I can just send ~1/7th of the population to the camps.;)
The 2d coward has correctly pointed out the flaw in your arguement. Fitt's Law has nothing to do with the edges of the screen per se. It is about target acquisition.
The _reason_ that targets at the corners and edges of the screen are so notoriously easy to acquire however, is that you cannot overshoot, because the mouse will move no further than the boundary of the screen.
For example, if you set up two monitors on a Mac, and positioned the 2d one logically above the 1st one, the Fitt's law advantage of the menubar is lost, because it has become possible to go above the menubar region.
If a target is already acquired as a target however, there is no travel time or target acquisition time needed at all! You are already there! Tog has an article on his website, asktog.com, called "A Test to Give You Fitt's" or something like that, which can go into this further if you like.
As for your comment regarding unused menu items in a contextual menu... First, what does this have to do with Fitt's Law? Second, a good contextual menu will only show appropriate options, with the rare exception. There really shouldn't be unusable menu items in a contextual menu.
Would you prefer that you pay the lawyer up front with no guarantees that you'll win? He's taking a risk, and if you lose, at least you can walk away scot-free.
Contact your state bar and inquire about pro bono programs. Many lawyers do a certain amount of pro bono work, and they may be able to set you up with someone. I know that the school I go to (in NJ, sorry) also does some of that, but of course, we're not lawyers, and we try to only take in people that really have no other options at all.
It's not legal advice because 1) if he were wrong, and you had operated under the assumption that he was correct, he could be held liable and 2) because lawyers can only practice in jurisdictions in which they're licensed. Unless he's allowed to practice law in your state, he'd be seriously screwing himself over.
1) Because mice themselves are not an example of an intuitive interface. No one really ever seems to know what it is, or how to use it, until they've seen it in action. (whereupon it also is revealed as a really easy to use interface)
2) Because contextual menus -- if implemented in a worthwhile way, with proper commands et al -- are the single best menus from a Fitt's Law viewpoint. The time to travel to the location where the mouse already is is 0, and that makes for a pretty infinitely large single pixel. (nb of course that the contextual menu at the cursor's current location may not be appropriate, but it's still a good idea)
3) Because Jef Raskin simply decided to go with a single button by fiat. IIRC he did no user testing. He had seen how multiple mice were used on one of the only other systems to support them widely, the Alto, and hadn't liked it. He was supported in this by only a few people, but they were the only ones who cared either way. I seem to recall reading in his book, or in something online that if he had done testing over a longer period of time, the desirability of modified clicks might have come up. (on the plus side, click-drag-release behaviors were a result of this)
4) Personally, I'd join the ranks of UI experts, not that I consider myself to be one, who advocate adding a second button. Personally, I'd probably have two additional buttons, for symmetry, so that it was useful for lefties. I'd have the software support left handed button assignments and cursors. The main button would be as large as possible, for ergonomic reasons, and the secondary buttons pretty small. For purposes of distinction, they'd be a different color and texture, and have a glyph -- perhaps an arrow cursor w/ menu, on them. If it had an optical sensor, it would be located as far forwards as possible, for maximum control. Even if a plastic periscope was needed. Perhaps I'd find a way to work in my thumb side-mounted jog wheel idea too.
Anyway, I like the Mac, but it's important to sort the legend from the reality.
Well, I think that what they mean is not that if there were no anti-hacking law at a time when you hacked that you'd fall under this, but rather if you broke an anti-hacking law at any point in the past, action may always be taken against you. The statute of limitations, remember, is how long the government, or a civil plantiff have to bring suit before the action is so 'stale' as to no longer be worth hearing.
Well there have been weird issues similar to that before... the hardware guys _seriously_ had to work to squeeze a 512 x 384 one-bit display out of the Mac's hardware back in the 80's.
Obviously the mouse thing is a joke, but there have been instances where that wasn't terribly far from the truth either.
Slashdot Mirror
While I think that NextStep itself played more of a role than you give it credit for, let's discount that for the moment. Now replace 'Next' with 'Apple,' stick Steve at the helm... and I find that unless Apple had made a spectacular effort to turn around, an almost impossible one, that they're repeating some non-technically oriented mistakes of the past as well.
I use Macs all the time, own a G3 BW, been using them since the mid-80's, used to sell and repair them... I think my Mac credentials are in good order, thanks.
I also have a NeXT Cube that I used to use (hm, I could probably sell it now... I need the cash) and I completely agree with you that OS X is OpenStep 6. But I contend that OpenStep was, while a user friendly Unix, not as user friendly as any OS out there. MacOS, BeOS, and even Windows beat it in those regards.
MacOS 8 did not introduce the control strip, and while I agree that spring loaded folders and popup windows (the latter, one of my favorite things) are great innovations, they do kind of pale before the work done earlier. Platinum is a skin, I'm afraid, and that's pretty minor. Of course, Apple laid off a lot of key HCI staff just after System 7 was done, and most of the rest trickled out not awfully long afterwards. They're sitting on a mountain of good UI concepts, but little is being produced. I've been fortunate enough to see little glimpses here and there, though things are often under wraps. Quite a lot of the things that came out in the 90's were in fact developed by third parties!
Sheets are about the best thing I've seen in OS X, I'm afraid.
Anyway, looking like Unix is quite a different thing from behaving like Unix. Behavior, really, is more fundementally important than appearance. (though I'm not discounting the latter) And in that respect, there's not been much improvement AFAICT.
The appeal to other Unix users is probably going to be more minimal than you think. Apple hasn't got the experience or products to move into the medium-high end server market. (hell, you can't even rackmount their stuff easily) And on the low end, you've got to contend with x86 commodity hardware that can be dual booted into Windows if necessary. I'd be a little more encouraged if they migrated to x86, but that's probably not going to happen.
The reason that they must address the existing user base first is simple, really. It's the only one they have. Perhaps Apple can attract other customers. But given the high barriers to entry, regarding incompatable software and expensive niche hardware, and the better/good dichotomy, gambling that new customers can be brought in at the expense of old customers is insane. It's an absolutely ridiculous risk to unecessarily run.
As for UI testing, I really, really doubt that there was much at all. The UI is too unpolished -- it bears the hallmarks of something that was designed by fiat, designed by artists, and not designed by HCI designers. Most UI experts that have weighed in at all have tended to agree, several of whom have worked at Apple.
You remark that the previous UI didn't move many boxes. Well, the commercial success of OS X has, of course, yet to be realized. But are you seriously proposing that regression would work better? DOS sold bajillions of boxes... but I'm not hearing much call for that any more.
NextStep, upon which OS X is clearly based, sold hardly anything at all... I'd give MacOS more credit. Even in the face of MS, it was the only OS with any desktop popularity at all, besides Windows, though Apple squandered it for ages.
While of course, different users will have different preferences, HCI is more of a science than you seem to believe. Objective user testing and creative thinking can in fact determine _just_ how much of an improvement something is for various classes of user.
Given that, based on inclination to go with the Mac platform, prior investments, planned usage, and populations, the order of users whose needs should be addressed, and who should be attracted basically goes: Mac, Windows, newbies, Unix, misc. it's really mysterious as to why, for example, OS X would have Unix-like user directories, or a terminal divorced from the GUI.
Of course, Apple has done little HCI work that is seriously innovative since System 7. So it's not too surprising. Personally, I'm always suspicious when I see some Unix feature that was never in popular use crop up in OS X. It's tough for me to imagine that there could be so little improvement to UI than what was done by two guys in the late 60's.
Were there ideas that were quite cutting edge, that were nicely polished (e.g. directories that refresh themselves, much like System 1's did, hierarchical menus not limited to five levels, etc.) I'd be less critical of their overall efforts, and could concentrate on the substantive nature of the UI itself. Right now, there's not much that's new to go on.
Regarding metadata, there are other ways to handle cross-platform issues that preserve metadata, as well as new features that could be provided by the OS and documented in the HIG, such as auto-appending suffixes to outgoing flat files, etc. Apple's regressing to the old ways, and it's not all that necessary. NTFS has good support for metadata, for allied things like forked files, and is the coming standard. Apple's getting left in the dust, and ironically is NOT being a terribly good neighbor.
UI is better in some respects, but a step down from MacOS, and by no means an improvement to the state of the art.
Security model hasn't changed.
Speed's not amazing, though at least 10.1 is an improvement over the earlier releases.
Metadata's being depreciated.
I'm sorry, I'm not seeing that it's a substantial improvement on Unix, OR that Unix is a particularly desirable choice of OS for ordinary people. (Frankly, they could all stand significant improvement)
Except of course, that this ignores the lessons regarding Unix's abyssymal UI; ignoring the lesson that OS demands on hardware have to be as minimal as possible (esp. wrt the graphics system); ignoring areas where Unix could stand improvement, e.g. security models, filesystems, etc., etc.....
Unix is not the end all be all of OSes. Reimplementing it means that EXACTLY the mistakes of the past will be made, as opposed to a random assortment of mistakes and successes -- including new ones -- by trying something different
Exactly. It is in no way a jurisdictional action, and that is what many, many more networking cases tend to revolve around. Here it is just how zoning law is applied.
The court has merely interpreted the zoning law to be intended to prevent the activities of some defendant from upsetting the activities of some plaintiff. If I opened a piledriver testing facility next to a hospital, that would be in violation of the zoning laws regarding sounds.
If I could _mute_ the piledrivers so that there was absolutely no alteration in the condition of the people at the hospital whether they were on or off, I would not be in violation of that particular law.
That it involves the internet really has nothing significant to do with it
I'm not trolling. I'm saying there is a difference between a user and a users' software, and that further granularity (e.g. barring spyware from accessing system resources like the network, or from being executed, etc.) are desirable. But see the other reply for more.
True -- a user can often work around any security, particularly around the lax amount that is preferred for otherwise optimal working conditions.
.cshrc) or to files of a different type than they create or work with (e.g. textfiles to a graphics editor).
But -- It seems fairly unusual that you would need to give any given downloaded executable access to everything across the board. What does Photoshop need with rwx to my mail? Why would I give a calculator program access to the network? I'm simply saying that there should be more granularity. Without the user at the console manually doing it, most programs do not need access to certain reserved files (e.g. for programs not already explicitly trusted by the admin, it's probably safe to forbid writes to
Will this stop all malicious software? No, of course not. But it will further tighten the noose, and provide resources for a user or admin who wants to cut off the air supply to some of that such software. It also at least helps to constrain the amount of damage that parasitic malware can do -- if Outlook were restricted to write access to its own mail files, network connectivity, and the ability to read files that the user at the console had attached, it can screw with your mail, but at least it's not going to wipe out your textfiles.
I'm really not trolling here; it seems to me that once you get through the single layer of security protecting the user, as so many things do, you're giving who knows what the keys to the castle. Further compartmentalization, at least the possibility of it if the user desires it, seems reasonable.
Naw, that's not valid.
.exe suffix, and tried to run it.
;)
If I took an executable and changed the type/creator codes, it will no longer be recognized as an executable by the system. Rather as though if you stripped a Windows program of the
Forked files are actually pretty cool. If you're using the NTFS filesystem on Windows, you have them too! And IIRC Linus wants them to become commonplace on Linux, if only for intercompatability reasons. So you'd probably look into what they actually do do, pretty quick
Sounds like a major bug in Unix, to me. It's things like this, that are just assumed to be the way that things are, that really get under my skin. There are, I understand, alternative security models (I'm mostly thinking of capabilities, here) that would eliminate this security hole. But God forbid that Apple actually innovate anymore -- no, it's the NeXT way or the highway.
No. If for example, there were no license at all, the transfer would be entirely legal. The issue is whether the license is binding, or whether the default no-license state is defaulted to.
The use of the thing is not governed by copyright law unless the use is a special one that involves wide dissemination, e.g. public performance.
Specifically with regards to software, the creation of copies necessary in order to operate the software (e.g. copies from CD to HD to RAM) or to back it up, provided that it was otherwise purchased legally, and are not retained if the software is sold or otherwise disposed of, are legal.
But this is largely irrelevant. We're talking contracts. Mostly, we're talking, are the EULAs valid contracts?
Okay look, software is a red herring here. The fact that they're selling you software has absolutely nothing whatsoever to do with anything.
They could be selling you a book, or a car, or anything. Doesn't matter.
And there's no question that it is legal to agree to an explicit contract wherein it is stated that you cannot resell the good that was sold to you via that contract. That's perfectly legal, unless there were something else altogether that could void the contact.
The question is are EULAs, because of the way in which, and the time at, they are presented, legal contracts.
If you went down to the Ford dealership and they sold you a car, and in the glovebox was a slip of paper saying "by driving this car you agree that you cannot resell it" we'd be having the same discussion. Don't get hung up on software. There's nothing terribly special about software in this regard.
Any good could be considered as a service by that line of non-reasoning. (e.g. 'I bought a car' v. 'You bought the right to go places, not a car')
No, the truth of it is that you bought a copy of a work. Rather like a book. And a hundred years ago, it was determined that copyright holders cannot, merely by virtue of their copyright, restrict in any way, people from reselling that work. It's called the First Sale doctrine.
The question really is whether or not the licenses included with software are valid in whole, or in part, and if so, at what time do they become active? It has very, very little to do with software specifically, but rather contract law in general.
and then there's this, by some of the designers who built the mice themselves:
So it appears that the one-button mouse was developed by Raskin, and supported by a few people, around whom a consensus naturally grew, _prior_ to the full-fledged design or testing of the UI at all, and founded on little more than Raskin's personal experiences with Alto mice. There may have been after-the-fact user testing, but no one has seemed to discuss this. As I am very interested in computing history, I would be very grateful if you could point me to someplace that contraverts this point, and which has some weight behind it. (honestly, it's interesting to me, no joke)
As for the early Mac interface, remember, an intuitive UI is one that people can pick up immediately. An easy-to-learn UI is one that requires actual effort to learn, but very very little. Given that the Mac had to ship with really good documentation (I still have copies), audio casette tapes, posters, etc. back in '84 and still people often had a hard time 'getting it' (e.g. the disasterous Test Drive promotion) I wouldn't call it intuitive, so much as very easy to learn. There is a minor, but important difference, i.e. if a mouse was intuitive, people would know what to do with it the first time they see it, rather than learning how to use it easily by watching someone use it for all of five seconds.
No, the ergonomic advantage of some of the good Mac mice -- I'm thinking of the ADB II mouse and the USB Pro mouse, here -- are that several fingers are engaged in depressing the button. This reduces strain on any particular finger either in relative frequency, or in amount of exertion necessary.
;)
I _really_ like the ability to adjust the resistance of the USB Pro mouse in fact. That's another must-have feature.
I'm thinking of something approximately the size and shape of the ADB II mouse, or the blue, optical Logitech Wheel mouse. Let's leave out the thumb jog for the moment -- I'm still hashing that out, and it might indeed be something that can't be tackled on a symmetrical mouse while still retaining economy. The entire forwards section of the mouse, from the bump to the tail would be the main button. No matter which hand you operated it with, there would only be a single primary. The secondary buttons would probably be small flush buttons in a position to be depressed by the fingertip of the first finger (one for the left, one for the right) if rolled slightly away from the primary button.
I don't like the left/right button dichotomy. I prefer primary/secondary, and that's easily reinforced through size. The 2d button for the wrong hand of course, whichever that happens to be, probably winds up being a useless tertiary both in terms of functionality and ergonomics, but this isn't something I delve into a whole lot.
Plus I'm a rightie, so in a pinch I can just send ~1/7th of the population to the camps.
The 2d coward has correctly pointed out the flaw in your arguement. Fitt's Law has nothing to do with the edges of the screen per se. It is about target acquisition.
The _reason_ that targets at the corners and edges of the screen are so notoriously easy to acquire however, is that you cannot overshoot, because the mouse will move no further than the boundary of the screen.
For example, if you set up two monitors on a Mac, and positioned the 2d one logically above the 1st one, the Fitt's law advantage of the menubar is lost, because it has become possible to go above the menubar region.
If a target is already acquired as a target however, there is no travel time or target acquisition time needed at all! You are already there! Tog has an article on his website, asktog.com, called "A Test to Give You Fitt's" or something like that, which can go into this further if you like.
As for your comment regarding unused menu items in a contextual menu... First, what does this have to do with Fitt's Law? Second, a good contextual menu will only show appropriate options, with the rare exception. There really shouldn't be unusable menu items in a contextual menu.
Don't knock contingency.
Would you prefer that you pay the lawyer up front with no guarantees that you'll win? He's taking a risk, and if you lose, at least you can walk away scot-free.
Contact your state bar and inquire about pro bono programs. Many lawyers do a certain amount of pro bono work, and they may be able to set you up with someone. I know that the school I go to (in NJ, sorry) also does some of that, but of course, we're not lawyers, and we try to only take in people that really have no other options at all.
(not lawyers... yet! mwahahaha)
It's not legal advice because 1) if he were wrong, and you had operated under the assumption that he was correct, he could be held liable and 2) because lawyers can only practice in jurisdictions in which they're licensed. Unless he's allowed to practice law in your state, he'd be seriously screwing himself over.
Er, that's not especially relevant, however.
1) Because mice themselves are not an example of an intuitive interface. No one really ever seems to know what it is, or how to use it, until they've seen it in action. (whereupon it also is revealed as a really easy to use interface)
2) Because contextual menus -- if implemented in a worthwhile way, with proper commands et al -- are the single best menus from a Fitt's Law viewpoint. The time to travel to the location where the mouse already is is 0, and that makes for a pretty infinitely large single pixel. (nb of course that the contextual menu at the cursor's current location may not be appropriate, but it's still a good idea)
3) Because Jef Raskin simply decided to go with a single button by fiat. IIRC he did no user testing. He had seen how multiple mice were used on one of the only other systems to support them widely, the Alto, and hadn't liked it. He was supported in this by only a few people, but they were the only ones who cared either way. I seem to recall reading in his book, or in something online that if he had done testing over a longer period of time, the desirability of modified clicks might have come up. (on the plus side, click-drag-release behaviors were a result of this)
4) Personally, I'd join the ranks of UI experts, not that I consider myself to be one, who advocate adding a second button. Personally, I'd probably have two additional buttons, for symmetry, so that it was useful for lefties. I'd have the software support left handed button assignments and cursors. The main button would be as large as possible, for ergonomic reasons, and the secondary buttons pretty small. For purposes of distinction, they'd be a different color and texture, and have a glyph -- perhaps an arrow cursor w/ menu, on them. If it had an optical sensor, it would be located as far forwards as possible, for maximum control. Even if a plastic periscope was needed. Perhaps I'd find a way to work in my thumb side-mounted jog wheel idea too.
Anyway, I like the Mac, but it's important to sort the legend from the reality.
Well, I think that what they mean is not that if there were no anti-hacking law at a time when you hacked that you'd fall under this, but rather if you broke an anti-hacking law at any point in the past, action may always be taken against you. The statute of limitations, remember, is how long the government, or a civil plantiff have to bring suit before the action is so 'stale' as to no longer be worth hearing.
That's weird and rambling, but surprisingly good. I liked it. Too bad no one's selling Batmobiles anymore though, however.
Well there have been weird issues similar to that before... the hardware guys _seriously_ had to work to squeeze a 512 x 384 one-bit display out of the Mac's hardware back in the 80's.
Obviously the mouse thing is a joke, but there have been instances where that wasn't terribly far from the truth either.