Would I be trolling if I say that I think Jef Raskin is totally overrated?
I read parts of his book, The Humane Interface, and I would have to agree with you: he seems to value "flow" over more important considerations.
For instance, Raskin deems that having to enter both a username and password when logging onto a system is "identifying yourself to the system twice". He argues that it would be better to generate a unique password for each user, and then have the user enter just the password to accomplish login. Utopia! I suspect, however, that actual users would much prefer to type in their username and have the ability to set their own passwords.
One sort of cool idea he promotes is the idea of a "hermaphrodite" universal cabling system where any 2 cables of the same gauge could be plugged into each other, freeing people from the tiresome burden of adapters, couplers, and male-female converters. However, if you are wiring up a computer in the dark (or in a difficult-to-reach corner), you quickly come to appreciate the fact that the ethernet cable ONLY plugs into the ethernet card, the monitor cable ONLY plugs into the video card, etc.). He doesn't seem to see these sorts of downsides to many of his ideas.
There are situations where a particle/system/etc. can probabalistically be in one of several states. But until someone or something measures it to determine which state it is in, "the universe hasn't decided yet".
My question is: what constitutes "measurement"? If someone performs the cat experiment in a closed room, does the room itself exist in a probablistic state to observers outside the room? If not, then how come the cat's observation was not sufficient to collapse the probability wave? What's special about the human observation?
Does this question carry over to the wave/particle determination of a light source? As I understand it, the observer can choose the outcome he prefers (be it to observe the light as a "wave" or "particle"). By doing this, he fixes the outcome that any "downstream" observer can derive by looking at the same light. Correct? But what constitutes an observation of the light? Can a machine make the initial determination and hence "transmit" information to future observers?
In a word, what is it that forces the universe to make up its mind?
Minor comment: what you're really saying is that someone can always be blamed. I do not disagree per se, but in determining the people who failed, we humans are also quick to penalize those individuals by judging them against standards far higher than we would want imposed on ourselves.
Grandparent post: Saddly, the whole "it looks different than Windows" is a major issue with my wife.
Parent post: Can't you get skins that make the Linux desktops and apps look like Windows?
My intuition is that this superficial simularity makes the situation worse. A look-alike windows theme will still contain subtle differences that give users the impression they are looking at an ugly knock-off. (We could draw parallels here to the uncanny valley effect.)
Finding the right theme to convert Windows users is tricky. You will get the best results with something that preserves most of the behaviors (esp. button locations/functions on the window frame) of Windows, but that is visually distinct from Windows. You want something that is aesthetically conservative, yet superior. Instead of knock-off, you want "a new computer" [but not something overwrought that looks like an alien console]. Personally, I think Plastik for KDE gets its right (although that screenshot may not do it justice): it's not fancy or ugly, and it has some subtle mouse-over behaviors that make the window system seem... attentive.
Again, this is all intuition: nothing beats actual user research. Also, keep in mind that people who are afraid of computers will have a mental block against trying new things. This is natural: we humans resist situations where our strategic knowledge is no longer valid. Reaching this type of user will require a whole new level of approach beyond making the product act like Windows.
the person who runs the tracker has set it up with the intent to share the specific file being shared
I understand your basic argument, but many bittorrent tracker sites let users upload new torrents. E.g., the person running the site does not have "the intent to share a specific file".
just attack the one facilitating the downloads
There are a lot of people and companies facilitating the download. The system would not work without ISP's, search engines, networks, hardware companies, and about 2 generations of technology researchers, pioneers, and entrepreneurs. The owner of the tracker is the easiest target for multiple reasons:
No laws have been passed to protect the tracker owner (unlike ISP's, etc.).
The tracker owner is the most cost-effective target for achieving the desired result.
The tracker owner is in the best position to (a.) know that his service is being used to facilitate copyright violation and (b.) take some policing action to compensate.
I suspect that item 3 provides the moral backbone of your opinion while items 1 and 2 make it expedient. However, note that item 3 applies (with less severity) to every party who has facilitated the transfer.
So the question is: do you see this just as a matter of degree? E.g., are we suppose to start classifying services as "basically legitimate" and "basically illegitimate" and start passing laws, issuing warrants, and conducting lawsuits from that standpoint?
Before you answer, keep in mind that every innovative technology
gets viewed as illegitimate at some point. Will our desire to protect certain business models today compromise the level of technology available to our children tommorrow? Will we delay the cure for cancer 20 years to protect the margins of the James Bond franchise?
Okay... sorry for the emotional plug in that last paragraph. I admit that I don't have an easy answer for this problem. But the temptation to reach for easy answers is what worries me in this debate...
Compare the security woes of Microsoft or Linux with the rock-solid experience of OpenBSD
This is a pretty bad example. OpenBSD's security does not stem from up-front design as it does from iterative refactoring. In addition to disabling most services by default, etc., their basic strategy has been to revisit/re-walk the code everytime they learned of a new type of problem (e.g., buffer overflow, etc.). A better example might be Linux vs. Hurd or Windows vs. Macintosh... in both of these cases, superior product design was undercut by a less perfect but nimbler competitor.
Our ability to think and reason was not the product of evolution, but was deliberately chosen for us. Perhaps this is a thought that should again be applied to the creation of software.
Our ability to think and reason is highly flawed. The whole point of iterative design is that you bring external validation into the development cycle as early as possible. If we had a divine ability to see the entire problem and solution up-front, then yes, up-front design would be most effective. If you're confident you can do the up-front design, by all means do it... software design is hard, and you need a cunning mix of strategies to do it successfully.
If you really believe that, buy stock in those corporations and you'll get your money back. If they are that well-subsidized, it's a no-risk investment.
Don't believe it.... you will be able to speak it in less than 2 years.
Proof? This contradicts everything that my linguistics professors told me while learning about childhood language development, etc. You might be right, but I'd like to see the research and understand how my profs (and textbooks) were so in the dark...
BTW, linguistics makes a great side-study for computer science majors. Learn about lab chimps, brain damage, language families, and other fun topics while racking up social science credits (or humanities credit, at some schools). On top of that, there are some nice parallels b/t compiler theory and human language processing...
If you can't handle the technology, DON'T USE THE TECHNOLOGY
Obviously an ureasonable attitude, except in certain narrow situations. Assigning blame does nothing to provide a solution, and dismissing everybody from the internet is neither reasonable nor desirable.
Re:From a scientist: not just politics as usual
on
Bush vs. Kerry on Science
·
· Score: 2, Insightful
Scientists are as biased as pastors.
I see two occupations. One group uses systematic processes. For their conclusions to be taken seriously, they must expose (1) assumptions, (2) observations, and (3) reasoning. In theory, and often in practice, anyone can come along behind them and retrace their footsteps to arrive at the same conclusion. Scientist, as it were, must play with their cards on the table.
The other group (pastors) do not operate with this constraint. Any idea can be presented so long as scripture is spinned correctly and the idea itself jives with the audience's expectations. Fringe represenatives of this group (witchdoctors, cult leaders, etc.) can claim Special Revelation from Above (or Below or Within) that nobody else has access to.
Maybe the pastor sees further than the scientist, but the latter seems to produce knowledge that is more strategic in the real world (viz., for winning wars, conquering disease, exploring space, bridging rivers, understanding weather, etc.).
Your point that "all are biased" is trivial. Knowledege is an extremely tricky and difficult terrain to navigate, but some biases are much more effective at boosting accurancy than others. At its core, science is just a process that tries to correct for known human tendencies; this process can and has been practiced by people of all religions and those of none.
If you can't think of anywhere EXCEPT a context sensitive menu to put something, it seems clear to me you haven't really thought about the design at all.
The parent to my post was claiming that context menus should never be used. I'm not arguing that operations should be exclusively put in the context menu... by all means, communicate to the user through all feasible channels possible.
My comment about "text" on the toolbar being superior to icons was based on research experiments my professors have cited... I've got no reason to doubt them. The disadvantage to text is that it takes up more real estate, and sometimes wording is tricky.
Finally, UI is hard. I frequently see "brute-force" application of UI philosophy that misses the point. There is no magic way to do it. That's what I meant by "slinging around" words.
Software ought not to require users to use context sensitive menus to perfom an operation - if it does so then it is badly implimented because most users will simply not figure this out (and if and when they do, it won't be until after a significant of time wasted searching for the way to do it). Context menus... should never be the only way to perform a given operation.
While we're carelessly slinging UI philosophy around, let me mention that context menus seem very much in line with the philosophy of "direct manipulation". When the user wants to know "what can I do with this object?" they can right-click and find out.
Now... let me ask: if you don't put the operation in the context menu, where are you going to put it? You could make (i) a gesture (as in drag-and-drop, delay-click, or text selection), (ii) put something underneath the main menu of the application that operates on that object , (iii) put some buttons in the toolbar, (iv) put buttons around/near the object, or (v) have the user click on the object and get a large dialog box offering all possible options.
These can all be good options in the right situation, but they involve tradeoffs. I would argue that ALL operations that can be meaningfully done on an object should be placed into the context menu (space permitting) and then optionally "hoisted" to one or more of the places I identified.
Things to think about...
The problem with (i) ["gestures"] is that it is even more "hidden" than putting something in the context menu. A gesture will work well when it's implemented system-wide and integrated with user training (such as in the examples I gave). Highly domain-specific gestures can be difficult to discover in a casual application. They are also costly to implement.
The problem with (ii) ["main menu"] is that it substantially more hidden than the context menu. It can be difficult to determine which operations in the main menu apply to which items on the screen, and it gets even more confusing because these items frequently look at pseudo-modes [like "which item is selected?"]... this is effective in a document-centric application (where there is only one global "selection") but difficult in a form-centric application (where each listbox/datagrid has a different selection).
The problem with (iii) ["toolbar buttons"] is similar to (ii) in that there's a context-determination problem (and you loose the benefict of direct manipulation). It is slightly more costly to implement and slightly less costly to use than (ii). A toolbar button is marginally less hidden that the context menu item. I say "marginally less" because the icon for the toolbar button does not convey a lot of information about that button. (Experiments prove that people can use text toolbar buttons better... if you can come up with the right text.)
The problem with (iv) ["adjacent buttons"] is that screen real-estate is scarce. In some situations, this option can be costly to implement.
The problem with (v) ["dialog box"] is that you obscure a large portion of the screen and interrupt the user in order to perform the same task that the context menu performs more succiently.
My point is that good UI must be a matter of practice and economics; theory is useful for proposing and exploring long-term UI possibilities, but theory must be handled carefully by UI-practicioners... it's easy to be too rigid and overapply a usability princple and lose site of what [from the vantage point of the user's cognitive experience] made that princple important in the first place.
In my 8 years as an Oracle DBA I don't think i've ever seen a corrupt index. Saying that, I don't even know how you could force a index to get corrupted so I don't think were seeing all the info here.
FYI... try a destructive index rebuild on some tables that are being actively read/written to. (This is an Oracle 7.3 bug that bit us hard one time.)
Re:Not complete disagreement, but some clarificati
on
Lawyers In Space...
·
· Score: 1
Pretty interesting... thanks for taking the time to explicate.
It's spam, not SPAM. SPAM is a registered trademark of a certain food company that is graciously not suing the ass off of everyone, and asks only that we not capitlize the word.
I guess congress didn't research that when they wrote CAN-SPAM.
Be careful. Belief is complicated, and the typical atheist conception of a religious person is somewhat naieve. You might be interested in this article and this book. Both are written by Pascal Boyer, and he's done some great preliminary analysis of what drives religious beliefs.
Re:When did the Communists take over outer space?
on
Lawyers In Space...
·
· Score: 2, Insightful
Communism has been damn near wiped off the face of the earth and only in acadamia does it still exist.
I don't know about that... there's a little country called "China" that is still pretty fairly communistic. But for that matter, laze-faire capitalism has also been relegated to academia. Most nations today use a capitalist-leaning mixed-market economy.
And while I agree with your basic argument, note that property rights are not a "metaphysical truth", they are a psychological/sociological one. Keep in mind that the real question is "how can we as a society get maximum benefit from space?". Perhaps some of the scientist you refer to *want* space colonization to happen slowly, a la the anti-privatization treaties that keep people out of Antartica.
please elect experienced lawyers that know their way around case law
But that's the problem... the law should (ideally) be compact, concise, and predictable so that everyone can interpret it and use it. Everyone should be able to do determine (1) what their legally-recognized rights are and (2) what actions are considered illegal. They should be able to do this without having to study law for several years or read through the torturous, abstract, ad hoc philosophical contortions pounded out by judges past... we should be able to "do" law and order just by looking at the face of things.
Of course, this probably isn't possible due to the sheer number of things that laws must regulate. There's a lot of things, that, like it or not, it's very pragmatic to have some regulation on. But it would make for better law if there was a greater focus on keeping things as minimalistic as possible.
As one example, the law could be made more declarative and less procedural in nature. Here's what I mean: suppose that I am planning to go to the grocery store in a week's time. Every day, I think of new stuff that I need, and I add these items to my grocery list. Here's what my grocery list looks like:
1 bag of tortilla chips
4 jars of jalapenos
3 pkgs of hotdogs
Amend the text of item 2 to remove the words "jars of"
Found 2 pkgs of hotdogs in the freezer! At time of purchase, item 3 should be intrepreted as being the number of hotdogs listed in item 3 minus these 2 pkgs.
Something green.
Enough hotdog bugs to enclose the sum of quantities of hotdogs in item 3 had item 5 not been listed.
What a nightmare! It would be easier if I had maintained the list declaratively. At the end of the week, my list would have looked like this:
1 bag of tortilla chips
4 jalapenos
1 pkg of hotdogs
enough buns for 3 pkgs of hotdogs
1 head of lettuce
Law is the source code of civilized society: every effort should be made to incorporating good design and keeping it simple enough so that most competent adults can understand it.
The speed increase could be as much as 400% - not bad for giving up 1 meg of RAM.
You forget that the Mac IIsi came standard with 2 MB of RAM. You could probably upgrade it to ~say~ 32 or 64 MB RAM for the price of a small lear jet. You're talking early 90's, my friend...
(BTW, if you live in Birmingham AL and want a IIsi (4 MB of RAM!!), I have one in my basement that I'm about to trash.)
The basic unix security model is out-of-date, and is the source of many systemic problems.
Yes and no. For my home network, the unix security model is all I need. By contrast, my company has several thousand employees all accessing the same shared file system; I suspect that ACL's are absolutely critical in this environment.
The difference is that, on my home system, permissions are easy to apply and verify. At work, it's pretty difficult to know that things have been done right. Part of the problem is that Windows forces you to do it through the GUI, and their particular GUI for this is not as good as it could be. The main reason, however, is that ACL's are more difficult to reason about to begin with. This is a standard trade-off in computer science: increased complexity in your data model allows more local reasoning but less global reasoning.
That said, I hope that Linux finds a standard way of doing both traditional security and ACL security on future file systems. I just hope they avoid hair-splitting like Windows, which has seperate permissions for "write file", "write file properties", "write file extended properties", and "delete file".
I'd point out a similar issue with SID's... it's great that the model is so straightforward on Linux, but that does have drawbacks in the network environment.
Thanks for the link... it would be nice to see a more in-depth study, but this is interesting info. One note is that these numbers apply to the 9% of serious/fatal accidents caused by driver distraction.
Also, this does not really answer the question of whether passengers hurt or help the driver on the whole. You'd really need a breakdown of accidents by whether or not passengers were present (e.g., how many accidents per 100,000 miles does a solo driver encounter? How about for a driver with passengers? A driver with 1 adult passenger? A driver with 4 teen passengers?, etc.). The BCAA stats do not suffice because it may be possible that the passengers actively help reduce other risks in driving (such as adjusting those durn A/C and radio controls).
I agree this is unlikely, but I'm balking because the BCAA stats don't jive with my own experiences. There are a lot of potiential methodological/interpretative problems with this data. I need to research this further, and, if my intuitions are wrong or misleading, I need to take preventive measures with future passengers.
"Honest, Officer! All my passengers ride bound and gagged in the trunk. I was just taking Julie home because she wasn't sober enough to drive herself..."
I make no excuses for anyone on a non-handsfree cellphone.
Actually, I think studies have shown that handsfree and non-handsfree cellphones have a similar (negative) impact on driving safety. From an ergonomic standpoint, this implies that either handsfree cellphones have their own nuisances which impact driving safety AND/OR that the majority of risk comes from the social/mental distraction of conducting conversations, not ergonomics. I suspect the latter.
(Sorry... I don't have a link to prove this, but I heard it on NPR once, and a few times since. Take with a grain of salt.)
One related question would be: if cell phone conversations are unsafe, why does having a conversation with fellow passengers (presumably) not impact safety? A few speculations: passengers have an immediate appreciation for the situation that the driver is in, and they can respond to the moment with a number of strategies to help the driver focus. (Strategies include: softening the tension of the conversation, directing the driver's attention back to the road, handling navigation or child-management tasks, and good old STFU and/or screaming.)
Passengers are also a "set" group for the duration of the ride. The driver knows ahead of time what emotional climate to expect and what sort of conversation he's going to have. Compare to a cellphone-using driver who's talking with several different people during a ride, perhaps trying to resolve a stressful office or home situation. That's a lot of different information (and emotions) to handle all at once...
No, no, no... this does not work like you imagine. You can't put users in two separate buckets and pretend they never cross paths. It's difficult to articulate all the ways in which this scheme fails but let's outline a few scenarios:
A novice user needs help and invites an expert over. The expert sits down and discovers that it will take ~10+ minutes to resolve the problem. Resolving the problem would be easier if the expert features were enabled, so the expert has to delve into the dialog boxes, switch to expert mode, do all the work, and remember to switch the UI back to novice mode when he's done.
A documentation writer must choose b/t taking screenshots in novice mode or expert mode. When the expert is documenting, he may have to switch his UI to novice mode to get good screenshots, and then back to expert mode again.
Intermediate people will have no transition b/t "novice" and "expert" modes. (And don't even talk about adding more modes.) Switching b/t modes may be confusing for novice and expert alike. (A PITA when trying to give "blind" tech support over the phone.)
Programmers writing shell extensions will now have two UI's to target. Often, novice mode will not be taken into account early on, resulting in (*tah dah*) additional pain for novices.
The list goes on... instead of making one good UI, you end up making two crummy ones.
The alternative to this is to avoid modality through better design. You gave the example of a file selector dialog box. In KDE (and Windows, and probably Gnome and MacOS as well), you can graphically navigate (with mouse or keyboard) up/down/across your entire file system. You can also type a full path in the "Location" box, expert style. In KDE, the Location box responds by suggesting possible completions that narrow down as you keep on typing. Notice how rich the possible interactions are here: the user is not forced to choose which of two paths he wants to take via a control panel far ahead of time. Instead, the user can use a mixture of strategies to accomplish his goal... the dialog box even accommodates some peripheral file-management tasks (like creating an new folder) that are tangent to (but prerequisites for) the user's primary goal.
There are other interesting aspects of this: the distinction b/t novice and expert is often unclear. For instance, I'm quite familiar with Microsoft Word, and know several shortcuts for formatting text, manipulating the outline view, etc. I consider myself an "expert", but I wouldn't get very far if you took away the menus and expected me to rely just on shortcuts. Corny example, but my point is the same... even experts need to fallback on the navigation strategies that novices prefer. Really, the distinction b/t the two group flickers in and out... it's not that useful. If you really think that your expert users want something that cannot be integrated with how novices users do business, then you do not understand your users. (Either that, or your experts have been forced to use something really arcane for a long time...)
I will concede that expert/novice modes do make sense when they apply to very small granular options (like whether to have point-and-click focus or sloppy focus), but if you have to name the different modes by their intended audiences ("expert" and "novice"), then you've gotten too general.
Slashdot Mirror
I read parts of his book, The Humane Interface, and I would have to agree with you: he seems to value "flow" over more important considerations.
For instance, Raskin deems that having to enter both a username and password when logging onto a system is "identifying yourself to the system twice". He argues that it would be better to generate a unique password for each user, and then have the user enter just the password to accomplish login. Utopia! I suspect, however, that actual users would much prefer to type in their username and have the ability to set their own passwords.
One sort of cool idea he promotes is the idea of a "hermaphrodite" universal cabling system where any 2 cables of the same gauge could be plugged into each other, freeing people from the tiresome burden of adapters, couplers, and male-female converters. However, if you are wiring up a computer in the dark (or in a difficult-to-reach corner), you quickly come to appreciate the fact that the ethernet cable ONLY plugs into the ethernet card, the monitor cable ONLY plugs into the video card, etc.). He doesn't seem to see these sorts of downsides to many of his ideas.
Commercialization! We need to bomb them with S.I. Swimsuit issues and Brittany Speares CD's.
My question is: what constitutes "measurement"? If someone performs the cat experiment in a closed room, does the room itself exist in a probablistic state to observers outside the room? If not, then how come the cat's observation was not sufficient to collapse the probability wave? What's special about the human observation?
Does this question carry over to the wave/particle determination of a light source? As I understand it, the observer can choose the outcome he prefers (be it to observe the light as a "wave" or "particle"). By doing this, he fixes the outcome that any "downstream" observer can derive by looking at the same light. Correct? But what constitutes an observation of the light? Can a machine make the initial determination and hence "transmit" information to future observers?
In a word, what is it that forces the universe to make up its mind?
Minor comment: what you're really saying is that someone can always be blamed. I do not disagree per se, but in determining the people who failed, we humans are also quick to penalize those individuals by judging them against standards far higher than we would want imposed on ourselves.
Parent post: Can't you get skins that make the Linux desktops and apps look like Windows?
My intuition is that this superficial simularity makes the situation worse. A look-alike windows theme will still contain subtle differences that give users the impression they are looking at an ugly knock-off. (We could draw parallels here to the uncanny valley effect.)
Finding the right theme to convert Windows users is tricky. You will get the best results with something that preserves most of the behaviors (esp. button locations/functions on the window frame) of Windows, but that is visually distinct from Windows. You want something that is aesthetically conservative, yet superior. Instead of knock-off, you want "a new computer" [but not something overwrought that looks like an alien console]. Personally, I think Plastik for KDE gets its right (although that screenshot may not do it justice): it's not fancy or ugly, and it has some subtle mouse-over behaviors that make the window system seem... attentive.
Again, this is all intuition: nothing beats actual user research. Also, keep in mind that people who are afraid of computers will have a mental block against trying new things. This is natural: we humans resist situations where our strategic knowledge is no longer valid. Reaching this type of user will require a whole new level of approach beyond making the product act like Windows.
I understand your basic argument, but many bittorrent tracker sites let users upload new torrents. E.g., the person running the site does not have "the intent to share a specific file".
just attack the one facilitating the downloads
There are a lot of people and companies facilitating the download. The system would not work without ISP's, search engines, networks, hardware companies, and about 2 generations of technology researchers, pioneers, and entrepreneurs. The owner of the tracker is the easiest target for multiple reasons:
- No laws have been passed to protect the tracker owner (unlike ISP's, etc.).
- The tracker owner is the most cost-effective target for achieving the desired result.
- The tracker owner is in the best position to (a.) know that his service is being used to facilitate copyright violation and (b.) take some policing action to compensate.
I suspect that item 3 provides the moral backbone of your opinion while items 1 and 2 make it expedient. However, note that item 3 applies (with less severity) to every party who has facilitated the transfer.So the question is: do you see this just as a matter of degree? E.g., are we suppose to start classifying services as "basically legitimate" and "basically illegitimate" and start passing laws, issuing warrants, and conducting lawsuits from that standpoint?
Before you answer, keep in mind that every innovative technology gets viewed as illegitimate at some point. Will our desire to protect certain business models today compromise the level of technology available to our children tommorrow? Will we delay the cure for cancer 20 years to protect the margins of the James Bond franchise?
Okay... sorry for the emotional plug in that last paragraph. I admit that I don't have an easy answer for this problem. But the temptation to reach for easy answers is what worries me in this debate...
This is a pretty bad example. OpenBSD's security does not stem from up-front design as it does from iterative refactoring. In addition to disabling most services by default, etc., their basic strategy has been to revisit/re-walk the code everytime they learned of a new type of problem (e.g., buffer overflow, etc.). A better example might be Linux vs. Hurd or Windows vs. Macintosh... in both of these cases, superior product design was undercut by a less perfect but nimbler competitor.
Our ability to think and reason was not the product of evolution, but was deliberately chosen for us. Perhaps this is a thought that should again be applied to the creation of software.
Our ability to think and reason is highly flawed. The whole point of iterative design is that you bring external validation into the development cycle as early as possible. If we had a divine ability to see the entire problem and solution up-front, then yes, up-front design would be most effective. If you're confident you can do the up-front design, by all means do it... software design is hard, and you need a cunning mix of strategies to do it successfully.
The market has already factored that in...
4. China has massively upped their consumption of oil.
Proof? This contradicts everything that my linguistics professors told me while learning about childhood language development, etc. You might be right, but I'd like to see the research and understand how my profs (and textbooks) were so in the dark...
BTW, linguistics makes a great side-study for computer science majors. Learn about lab chimps, brain damage, language families, and other fun topics while racking up social science credits (or humanities credit, at some schools). On top of that, there are some nice parallels b/t compiler theory and human language processing...
Obviously an ureasonable attitude, except in certain narrow situations. Assigning blame does nothing to provide a solution, and dismissing everybody from the internet is neither reasonable nor desirable.
I see two occupations. One group uses systematic processes. For their conclusions to be taken seriously, they must expose (1) assumptions, (2) observations, and (3) reasoning. In theory, and often in practice, anyone can come along behind them and retrace their footsteps to arrive at the same conclusion. Scientist, as it were, must play with their cards on the table.
The other group (pastors) do not operate with this constraint. Any idea can be presented so long as scripture is spinned correctly and the idea itself jives with the audience's expectations. Fringe represenatives of this group (witchdoctors, cult leaders, etc.) can claim Special Revelation from Above (or Below or Within) that nobody else has access to.
Maybe the pastor sees further than the scientist, but the latter seems to produce knowledge that is more strategic in the real world (viz., for winning wars, conquering disease, exploring space, bridging rivers, understanding weather, etc.).
Your point that "all are biased" is trivial. Knowledege is an extremely tricky and difficult terrain to navigate, but some biases are much more effective at boosting accurancy than others. At its core, science is just a process that tries to correct for known human tendencies; this process can and has been practiced by people of all religions and those of none.
The parent to my post was claiming that context menus should never be used. I'm not arguing that operations should be exclusively put in the context menu... by all means, communicate to the user through all feasible channels possible.
My comment about "text" on the toolbar being superior to icons was based on research experiments my professors have cited... I've got no reason to doubt them. The disadvantage to text is that it takes up more real estate, and sometimes wording is tricky.
Finally, UI is hard. I frequently see "brute-force" application of UI philosophy that misses the point. There is no magic way to do it. That's what I meant by "slinging around" words.
While we're carelessly slinging UI philosophy around, let me mention that context menus seem very much in line with the philosophy of "direct manipulation". When the user wants to know "what can I do with this object?" they can right-click and find out.
Now... let me ask: if you don't put the operation in the context menu, where are you going to put it? You could make (i) a gesture (as in drag-and-drop, delay-click, or text selection), (ii) put something underneath the main menu of the application that operates on that object , (iii) put some buttons in the toolbar, (iv) put buttons around/near the object, or (v) have the user click on the object and get a large dialog box offering all possible options.
These can all be good options in the right situation, but they involve tradeoffs. I would argue that ALL operations that can be meaningfully done on an object should be placed into the context menu (space permitting) and then optionally "hoisted" to one or more of the places I identified.
Things to think about...
The problem with (i) ["gestures"] is that it is even more "hidden" than putting something in the context menu. A gesture will work well when it's implemented system-wide and integrated with user training (such as in the examples I gave). Highly domain-specific gestures can be difficult to discover in a casual application. They are also costly to implement.
The problem with (ii) ["main menu"] is that it substantially more hidden than the context menu. It can be difficult to determine which operations in the main menu apply to which items on the screen, and it gets even more confusing because these items frequently look at pseudo-modes [like "which item is selected?"]... this is effective in a document-centric application (where there is only one global "selection") but difficult in a form-centric application (where each listbox/datagrid has a different selection).
The problem with (iii) ["toolbar buttons"] is similar to (ii) in that there's a context-determination problem (and you loose the benefict of direct manipulation). It is slightly more costly to implement and slightly less costly to use than (ii). A toolbar button is marginally less hidden that the context menu item. I say "marginally less" because the icon for the toolbar button does not convey a lot of information about that button. (Experiments prove that people can use text toolbar buttons better... if you can come up with the right text.)
The problem with (iv) ["adjacent buttons"] is that screen real-estate is scarce. In some situations, this option can be costly to implement.
The problem with (v) ["dialog box"] is that you obscure a large portion of the screen and interrupt the user in order to perform the same task that the context menu performs more succiently.
My point is that good UI must be a matter of practice and economics; theory is useful for proposing and exploring long-term UI possibilities, but theory must be handled carefully by UI-practicioners... it's easy to be too rigid and overapply a usability princple and lose site of what [from the vantage point of the user's cognitive experience] made that princple important in the first place.
FYI... try a destructive index rebuild on some tables that are being actively read/written to. (This is an Oracle 7.3 bug that bit us hard one time.)
Pretty interesting... thanks for taking the time to explicate.
I guess congress didn't research that when they wrote CAN-SPAM.
Be careful. Belief is complicated, and the typical atheist conception of a religious person is somewhat naieve. You might be interested in this article and this book. Both are written by Pascal Boyer, and he's done some great preliminary analysis of what drives religious beliefs.
I don't know about that... there's a little country called "China" that is still pretty fairly communistic. But for that matter, laze-faire capitalism has also been relegated to academia. Most nations today use a capitalist-leaning mixed-market economy.
And while I agree with your basic argument, note that property rights are not a "metaphysical truth", they are a psychological/sociological one. Keep in mind that the real question is "how can we as a society get maximum benefit from space?". Perhaps some of the scientist you refer to *want* space colonization to happen slowly, a la the anti-privatization treaties that keep people out of Antartica.
But that's the problem... the law should (ideally) be compact, concise, and predictable so that everyone can interpret it and use it. Everyone should be able to do determine (1) what their legally-recognized rights are and (2) what actions are considered illegal. They should be able to do this without having to study law for several years or read through the torturous, abstract, ad hoc philosophical contortions pounded out by judges past... we should be able to "do" law and order just by looking at the face of things.
Of course, this probably isn't possible due to the sheer number of things that laws must regulate. There's a lot of things, that, like it or not, it's very pragmatic to have some regulation on. But it would make for better law if there was a greater focus on keeping things as minimalistic as possible.
As one example, the law could be made more declarative and less procedural in nature. Here's what I mean: suppose that I am planning to go to the grocery store in a week's time. Every day, I think of new stuff that I need, and I add these items to my grocery list. Here's what my grocery list looks like:
What a nightmare! It would be easier if I had maintained the list declaratively. At the end of the week, my list would have looked like this:
- 1 bag of tortilla chips
- 4 jalapenos
- 1 pkg of hotdogs
- enough buns for 3 pkgs of hotdogs
- 1 head of lettuce
Law is the source code of civilized society: every effort should be made to incorporating good design and keeping it simple enough so that most competent adults can understand it.You forget that the Mac IIsi came standard with 2 MB of RAM. You could probably upgrade it to ~say~ 32 or 64 MB RAM for the price of a small lear jet. You're talking early 90's, my friend...
(BTW, if you live in Birmingham AL and want a IIsi (4 MB of RAM!!), I have one in my basement that I'm about to trash.)
Yes and no. For my home network, the unix security model is all I need. By contrast, my company has several thousand employees all accessing the same shared file system; I suspect that ACL's are absolutely critical in this environment.
The difference is that, on my home system, permissions are easy to apply and verify. At work, it's pretty difficult to know that things have been done right. Part of the problem is that Windows forces you to do it through the GUI, and their particular GUI for this is not as good as it could be. The main reason, however, is that ACL's are more difficult to reason about to begin with. This is a standard trade-off in computer science: increased complexity in your data model allows more local reasoning but less global reasoning.
That said, I hope that Linux finds a standard way of doing both traditional security and ACL security on future file systems. I just hope they avoid hair-splitting like Windows, which has seperate permissions for "write file", "write file properties", "write file extended properties", and "delete file".
I'd point out a similar issue with SID's... it's great that the model is so straightforward on Linux, but that does have drawbacks in the network environment.
Also, this does not really answer the question of whether passengers hurt or help the driver on the whole. You'd really need a breakdown of accidents by whether or not passengers were present (e.g., how many accidents per 100,000 miles does a solo driver encounter? How about for a driver with passengers? A driver with 1 adult passenger? A driver with 4 teen passengers?, etc.). The BCAA stats do not suffice because it may be possible that the passengers actively help reduce other risks in driving (such as adjusting those durn A/C and radio controls).
I agree this is unlikely, but I'm balking because the BCAA stats don't jive with my own experiences. There are a lot of potiential methodological/interpretative problems with this data. I need to research this further, and, if my intuitions are wrong or misleading, I need to take preventive measures with future passengers.
"Honest, Officer! All my passengers ride bound and gagged in the trunk. I was just taking Julie home because she wasn't sober enough to drive herself..."
Actually, I think studies have shown that handsfree and non-handsfree cellphones have a similar (negative) impact on driving safety. From an ergonomic standpoint, this implies that either handsfree cellphones have their own nuisances which impact driving safety AND/OR that the majority of risk comes from the social/mental distraction of conducting conversations, not ergonomics. I suspect the latter.
(Sorry... I don't have a link to prove this, but I heard it on NPR once, and a few times since. Take with a grain of salt.)
One related question would be: if cell phone conversations are unsafe, why does having a conversation with fellow passengers (presumably) not impact safety? A few speculations: passengers have an immediate appreciation for the situation that the driver is in, and they can respond to the moment with a number of strategies to help the driver focus. (Strategies include: softening the tension of the conversation, directing the driver's attention back to the road, handling navigation or child-management tasks, and good old STFU and/or screaming.)
Passengers are also a "set" group for the duration of the ride. The driver knows ahead of time what emotional climate to expect and what sort of conversation he's going to have. Compare to a cellphone-using driver who's talking with several different people during a ride, perhaps trying to resolve a stressful office or home situation. That's a lot of different information (and emotions) to handle all at once...
No, no, no... this does not work like you imagine. You can't put users in two separate buckets and pretend they never cross paths. It's difficult to articulate all the ways in which this scheme fails but let's outline a few scenarios:
The alternative to this is to avoid modality through better design. You gave the example of a file selector dialog box. In KDE (and Windows, and probably Gnome and MacOS as well), you can graphically navigate (with mouse or keyboard) up/down/across your entire file system. You can also type a full path in the "Location" box, expert style. In KDE, the Location box responds by suggesting possible completions that narrow down as you keep on typing. Notice how rich the possible interactions are here: the user is not forced to choose which of two paths he wants to take via a control panel far ahead of time. Instead, the user can use a mixture of strategies to accomplish his goal... the dialog box even accommodates some peripheral file-management tasks (like creating an new folder) that are tangent to (but prerequisites for) the user's primary goal.
There are other interesting aspects of this: the distinction b/t novice and expert is often unclear. For instance, I'm quite familiar with Microsoft Word, and know several shortcuts for formatting text, manipulating the outline view, etc. I consider myself an "expert", but I wouldn't get very far if you took away the menus and expected me to rely just on shortcuts. Corny example, but my point is the same... even experts need to fallback on the navigation strategies that novices prefer. Really, the distinction b/t the two group flickers in and out... it's not that useful. If you really think that your expert users want something that cannot be integrated with how novices users do business, then you do not understand your users. (Either that, or your experts have been forced to use something really arcane for a long time...)
I will concede that expert/novice modes do make sense when they apply to very small granular options (like whether to have point-and-click focus or sloppy focus), but if you have to name the different modes by their intended audiences ("expert" and "novice"), then you've gotten too general.