If one entity owns the exclusive rights in one country and another owns the rights in another country, you'd need to pay royalties to BOTH on EACH copy to sell region 0 DVDs, but you'd need to pay only one to sell region-crippled DVDs.
Satellite TV gets crippled for the same reason. Virtually every modern TV set is capable of receiving dual-channel audio. So it would be easy for TV stations to offer to their audience the choice whether to listen to the original audio track or the (often terribly) synchronized version in their native language. Some stations actually do this over here in Europe -- but never via satellite, only via cable or terrestrial transmission. The reason is simply that they would have to pay higher royalties for sending the original (i.e. english in most cases) audio track all over Europe.
But it may be protected by copyright, however absurd this may seem. In Germany (region 2) for instance there have been several seizures of region 1 DVDs. The reasoning behind: German Copyright laws grant to the copyright holder of any protected work the right to control its distribution. Copyright is more than just a right to receive compensation for a work being copied or used otherwise. Which may even make sense for the classical works of art the inventors of those copyright laws probably had in mind.
I believe that traditional copyright laws are just not suitable for modern style "content". Traditional works -- a painting, a statue, or something performed in a theatre or a concert hall, had a physical location. This started to change with books and newspapers becoming mass products. Nowadays, most works -- music, movies, everything on the Net, etc. -- are consumed in a way that involves making a copy for every single consumer. Even traditional theatre and opera performances are transmitted via television to thousands and millions of people, implicitly creating one copy per spectator.
Those who made our copyright laws probably had in mind copying paintings using paint and brushes. They certainly did not think of something like DVD, where the work to be protected just cannot exist without copying, since a whole collection of identical DVD copies is the work.
A few years ago every idiot i ran into tried to convince me of disabling Cookies while I still think it's a great idea.
Cookies certainly are a good idea, if for instance used to transmit session IDs or to save personalized settings. Being a developer, I use cookies myself for purposes like these. But cookies are also abused. It is not acceptable to me, and many other Web users, that a site one never deliberately requested something from, tries to set a cookie valid for the next fourty years with no visible reason. Who do they think they are? Wouldn't it be nice for them to first say: "Hello, my name is... and I would like to... ?"
I think it is this style of complete and perfect ignorance which upsets people and makes them turn off cookies. It basically says: "We are going to own your browser, and never release control to you."
If I were designing a browser, I would have a cookie monitoring window, which would log cookie activity.
If I had a choice I would prefer a browser that helps me to manage the various cookies (or better cookie-requests) rather than showing me all those cookies in a monitor window.
Cookie management here denotes something which allows to:
Reject cookies by originator, lifetime, or purpose, the latter one being particularly difficult to implement,
Accept cookies explicitly in certain situations, e.g. when clicking the save-my-settings button somewhere, and
Surf the Net undisturbed by cookie request dialog windows.
Compared to Netscape-style cookie warnings, such management would be actually usable and useful. It would give the user actual control instead of a simple cookies/no cookies choice. And such a scheme would preserve the option of using cookies where they offer some added value to the user, like in personalisation of sites.
Personally, I don't want to monitor cookies, I just want to ignore most of those having a lifetime of more than a few days. Web browsers should support this type of control.
let's implement md5sum's of webpages that appear at the bottom of the page, have some jscript that checks that md5sum against the actual md5sum of the page and prints out "this page has been modified" if that's the case.
Yeah, and trust the browser executing the code. Nice try. Circumvention of this "security measure"
would not even have to be deliberate; your idea may fail to work due to the way this stuff is implemented.
The crucial point here is that you cannot make any valid assumption about the execution environment of your JavaScript code. Not only that the hostile host problem has not yet been solved (and probably never will for general purpose PC-style computers), web design is also still platform independent by design. You can not even rely on your JavaScript code being executed at all.
Delaying the md5summing won't help you, as you still do not have any control over what is md5summed and where in the rendering chain changes to the page's appearance and functionality are actually made.
Current e-mail encryption is putting an additional load on the user. The user has to care about security at all, the user has to care about key management and trust settings, the user has to remember cryptography every time it is used.
If encryption ought to be used by mom and dad, and aunt Lucy, it has to be as easy to use as unencrypted e-mail. No additional mouse click, no additional message, no additional thinking. The sender's e-mail software determines whether the recipient is capable of receiving encrypted e-mail, retrieves keys if necessary, and encrypts messages whenever possible. If encryption is not possible, the message is sent in clear automatically. All this has to work without any specific setup phase right out of the box.
Given those side conditions it will be really hard to provide even a basic level of security. Encryption invisible to the user is prone to all kinds of attacks cryptographers hope to be prevented by sufficiently paranoid users. But the general user is neither paranoid nor an educated cryptographer, and won't be able to make the right decision either. Mom and dad don't know about
certificates, man-in-the-middle-attacks and stuff like that. They never will.
When bringing cryptography to the masses we have to leave the ideal world of Alice, Bob and Mallory. We have to sacrifice perfect security for usability, and focus on solutions which are good enough instead of provably secure. We may also exchange security for detectability to a certain degree, like suggested in another message around here. Where we cannot prevent them from snooping, we could at least try to make them make noise when snooping.
Before you start your protest: How many web sites "just know you" because your identity is stored in a cookie or in a bookmark? If the answer is none, how do you handle all those user names passwords? How many well-chosen distinguished passwords do you use? On how many sites? How often are they changed? Did you ever use the Please e-mail me my password again function on any site? Did you ever write down a password?
In other words: Are you, the software developer, the perfectly secure person you suppose the average user to be?
If this product proves popular, then this new form of currency could begin to impact the economy and some yet-to-be-quantified measure of the money supply.
Where do you see a new form of currency here? Do you consider tickets of all kinds, calling cards, or special rate telephone numbers as new froms of currency as well?
A lot of micropayment schemes had been proposed in the past. This one might work. Its inventors did not think about absolute security or cool cryptographic stuff. They thought about users and practicability.
The resulting scheme has several interesting properties:
It is easy to use.
Ok, usage could be even more easy, but at least it is no more difficult or inconvenient than using a credit card. A payment scheme for online digital goods and services requires convenience close to invisibility.
Thresholds are low.
The card does not require software installation, prior registration of the user, or sophisticated authorization procedures. Just get a card and use it, that's all.
It is easy to understand.
None of the many questions Joe Customer may possibly ask about a micropayment scheme has to be answered by using vocabulary from computer science or mathematics, or Alice-and-Bob-and-Mallory stories.
Customer's risk is limited and assessible.
There is no way a customer could lose more money than his card is worth at the moment -- and mom and dad can actually understand why. The scheme also allows for exclusion of fraudulent merchants.
Sufficient privacy is guaranteed by design.
The card is bought anonymously. Payments made with the same card can be linked, but as long as none of the payments is linked to a person, those data are virtually useless. In typical micropayment situations, there is no need to ask the customer for his name. There is even a strong contraindication against any avoidable hassle.
If a single card can be linked to a person, this relationship expires together with the card.
The card is mobile.
It can be used from any computer. No digital wallet, card reader, or other special equipment is needed. The customer doesn't need a computer at all. The scheme also works via WAP, SMS, or voice channels.
Transaction costs are low.
The most expensive thing probably is producing and distributing the cards. Anything else is handled by a computer somewhere on the net keeping a card numbers database and a merchants database and updating both if a transaction occurs.
I feel this is the best micropayment scheme ever designed. It just looks like user-centered design
and a good-enough-approach. There is however one thing that could turn it into another failure: lack of acceptance on the Net. In order to become a real success it has to be accepted by sites throughout the universe. Limited to.de it would be pretty useless.
Even open source developers don't live from air and water alone, and not all of them can make a living from doing things connected to open source. So give it a try.
Make sure the conditions are clear to both sides. Leave them enough time and freedom to continue their open source activities besides the job. Think about non-traditional contracts, which might for example leave the opportunity to re-use code under an open source license after a well-defined period of commercial exploitation under closed source conditions. Let them use open source tools thery are used to as far as possible without getting into license conflicts with your own stuff. Be honest. Provide them with good working conditions.
I mean, what with the liberal news media and their anti-microsoft slant you'd think it was good american programs like, oh, say.. Outlook that had 'viral' problems..
Mainstream media are not particularly bright at computer stuff. They confused 'being a platform for mobile agents' with 'having viral problems'. And you do, too.
Mundie tells us about research, inventions, intellectual property, and products, so let's question his words from a scientist's point of view. What, does he think, would a scientist prefer for her ideas? To sell them to $BIG_BUSINESS and risk them being thrown away for irrational reasons by suits who don't even understand them? It is a well-know fact that those who can afford it sometimes buy an idea just to make it vanish. Or would a scientist rather like the results and ideas to be implemented?
All those open source software developers actually implement ideas. No one requires Microsoft to pay them for it. They'll find their individual ways to make a living with or in spite of developing open source software. So what exactly is this guy talking about?
If we forbid modes, a TV remote control must have an on button and an off button.
On page 180 of Raskin's book you will find a case study showing this is not necessarily true. Raskin's example is about saving workplace state to a floppy disk, and he had the same considerations about modes. After describing a one-button solution, he concludes that the modality in this situation depends on the user's model.
Applied to the remote control: If one thinks of an on function and an off function behind the same button, there are modes. But if we watch it as, for example, a general "change actrivity state" function (in Raskin's book it's a "do the right thing with the disk" function), there are no modes.
Perhaps it's because there is no one single right way to make an interface, but there are many wrong ways. Software producers continue to make the same mistakes about what they think is user-friendly (yes, including GNOME and KDE by following the WIMP example), but Raskin shows that many of the usual assumptions are wrong (pretty much everything we currently understand about user interfaces, e.g. "icons are user friendly").
I don't think right and wrong are adequate categories here. In my opinion, the main problems in interface design are: there are not strict, absolute rules, and there are so many rules and trade-offs. As a result, most interfaces are a compromise between all those rules; they have to be. The interface designer's job is a multi-dimensional optimization problem.
Take colors for example. Designing a color scheme is a really hard task. One has to watch kind of side-effects, like brightness and contrast. One has to consider the possibility of color-blind users. Some combinations of colors strongly suggest a metaphor to the user, and should not be used if this is not intended; this applies namely to red-yellow-green which is likely to be associated with traffic lights -- in the western world. So cultural differences have to be taken into consideration, too.
Software developers tend to simplify and generalize the rules. That's what they are used to from programming. And they are seeking for recipes, for patterns. But there are no recipes and not many patterns for designing the user interfaces of sophisticated applications. Interface design needs skill, experience, the ability to watch your own creation with another one's eyes, and a will of iron to take every single problem of one's trial users seriously. And, of course, managers who do not sacrifice usability to deadlines and project plans.
This doesn't just apply to vi, of course, but anything sufficiently complex on a computer. Stick with one way and learn it.
The bad thing about vi is: once you learned it, you have to stick with it, because most other text editors will swallow your escapes and let the commands go through into the text.
In today's news, a German corporate spy plunged 108 stories to his death while attempting to scale New York's World Trade Center in efforts to steal business plans.
Why should everyone have to know how their computers work?
If not, why are crazy parents putting children in the age of four in front of their mast^H^H^H^Hcomputers then?
Working in the field of human factors, I fully agree with you in that it is the machines', or better the designers' and developers', fault if people encounter difficulties. Every careful reader of Don Norman'sThe Design of Everyday Things oder Jakob Nielsen'sAlertbox column knows that.
The interesting thing is, most people don't. They surely notice when getting confused by some software, web site, or gadget, but they are drawing the wrong conclusion that they had to learn how to use it, or that their children should learn it as early as possible, and things like that. Just a few hours ago I encountered a colleague who complained about usability of some web site. It took me a while to assure her there really are incompetent "web designers" who do not care about users and do not really understand the concepts behind web technology. And this happens over and over.
And things are getting worse. The Internet not only brought to us a lot of incompetence in user interface design, but also a tendency to make three steps backwards unnecessarily. We are told the web browser will be the user interface for everything in the future, because "everyone can use a browser" (how about the application inside the browser?), our personal computers get replaced by "thin clients", and typing on a mobile phone's tiny keypad is considered an adequate way of making payments. In short, we are going back to terminals and transactions, and beyond.
Even cool sites like/. are affected. I would prefer to type into a real text editor instead of this text entry box. I would like an auto-save function for everything I write built into my/. client, like the one in my favourite Usenet newsreader. I would really appreciate a more flexible, i.e. not page oriented, presentation of comments, which my favourite Usenet newsreader provides as well. Don't get me wrong;/. is quite usable if one considers the limited capabilities of a web browser. But those capabilities are not sufficient for most interactive applications.
I guess a lawyer service watching all my communications and warning me about what may become illegal in the next seven years will be the long-searched killer application for next generation (i.e. UMTS) mobile networks.
(...) but what would you say was the defining moment that facilitated public consumption of the technology? Was it a particular IPO, a particular announcement by a specific company?
Perhaps the first feminist campaign against digital pr0n? There actually has been one in Germany, back when the Internet still had been used mainly by academics.
Seriously, I believe it started when major newspapers began writing about it. You cannot tie it to a specific date. Since newspapers tend to copy from each other, only a small number of original articles was needed to spread the information that there is a thing called Internet. The technology had been available for years before, as well as access to online services, e.g. through Compuserve or local BBSs. Personally, I found the Internet attached to the back side of my first Unix account at the university back in '92.
Oh, and there was all that Information Superhighway babble from politicians. They still don't understand the Net, but they are doing a pretty good job telling everyone how to become a Super Couch Potato online.
Time and again the Linux crowd forget that normal people DO NOT USE LINUX BECAUSE IT HAS A COMMAND LINE. The sooner you get rid of xterm and kterm and the like, then we can consider Linux an OS for 'the rest of us'.
That's bull^H^H^H^Han oversimplification. Though it is true that a command line interface is not appropriate for the average user, pure existence of a command line is by no means a sign of user-unfriendlyness. There is not even a contradistinction between command oriented user interfaces and graphical ones. The paradigm of graphical user intarfaces rather includes all the less powerful paradigms invented before, e.g. command oriented, forms based, and menu based interaction, and adds further means of expression (direct manipulation, visual affordances, etc.) for the designer as well as for the user.
This is the major reason why GUIs survived for 20 years -- they do not inhibit experienced users by forcing them into newbie-style interaction, but provide expert-friendly interfaces which are learnable to newbies; at least the better ones do. And there is the only flaw of command line interfaces: they require a huge amount of learning and don't help the user with it.
Oh, by the way, the Windows 2000 thing that came with my laptop computer has a command line, too. Are there people who do not use it because of that?
Slashdot Mirror
Quoting X11(7):
"The X Consortium requests that the following names be used
when referring to this software:
X
X Window System
X Version 11
X Window System, Version 11
X11
X Window System is a trademark of X Consortium, Inc."
Satellite TV gets crippled for the same reason. Virtually every modern TV set is capable of receiving dual-channel audio. So it would be easy for TV stations to offer to their audience the choice whether to listen to the original audio track or the (often terribly) synchronized version in their native language. Some stations actually do this over here in Europe -- but never via satellite, only via cable or terrestrial transmission. The reason is simply that they would have to pay higher royalties for sending the original (i.e. english in most cases) audio track all over Europe.
But it may be protected by copyright, however absurd this may seem. In Germany (region 2) for instance there have been several seizures of region 1 DVDs. The reasoning behind: German Copyright laws grant to the copyright holder of any protected work the right to control its distribution. Copyright is more than just a right to receive compensation for a work being copied or used otherwise. Which may even make sense for the classical works of art the inventors of those copyright laws probably had in mind.
I believe that traditional copyright laws are just not suitable for modern style "content". Traditional works -- a painting, a statue, or something performed in a theatre or a concert hall, had a physical location. This started to change with books and newspapers becoming mass products. Nowadays, most works -- music, movies, everything on the Net, etc. -- are consumed in a way that involves making a copy for every single consumer. Even traditional theatre and opera performances are transmitted via television to thousands and millions of people, implicitly creating one copy per spectator.
Those who made our copyright laws probably had in mind copying paintings using paint and brushes. They certainly did not think of something like DVD, where the work to be protected just cannot exist without copying, since a whole collection of identical DVD copies is the work.
Wireless connection is the latest hot trend over here in Europe, and I think in the U.S. as well. Does this answer your question?
Cookies certainly are a good idea, if for instance used to transmit session IDs or to save personalized settings. Being a developer, I use cookies myself for purposes like these. But cookies are also abused. It is not acceptable to me, and many other Web users, that a site one never deliberately requested something from, tries to set a cookie valid for the next fourty years with no visible reason. Who do they think they are? Wouldn't it be nice for them to first say: "Hello, my name is ... and I would like to ... ?"
I think it is this style of complete and perfect ignorance which upsets people and makes them turn off cookies. It basically says: "We are going to own your browser, and never release control to you."
If I had a choice I would prefer a browser that helps me to manage the various cookies (or better cookie-requests) rather than showing me all those cookies in a monitor window.
Cookie management here denotes something which allows to:
Compared to Netscape-style cookie warnings, such management would be actually usable and useful. It would give the user actual control instead of a simple cookies/no cookies choice. And such a scheme would preserve the option of using cookies where they offer some added value to the user, like in personalisation of sites.
Personally, I don't want to monitor cookies, I just want to ignore most of those having a lifetime of more than a few days. Web browsers should support this type of control.
According to http://www.bigbrotheraward.de/ (in German), the Apache Software Foundation actually received one of last year's Big Brother Awards.de for the Apache Web server logging IP addresses in default configuration.
Yeah, and trust the browser executing the code. Nice try. Circumvention of this "security measure" would not even have to be deliberate; your idea may fail to work due to the way this stuff is implemented.
The crucial point here is that you cannot make any valid assumption about the execution environment of your JavaScript code. Not only that the hostile host problem has not yet been solved (and probably never will for general purpose PC-style computers), web design is also still platform independent by design. You can not even rely on your JavaScript code being executed at all.
Delaying the md5summing won't help you, as you still do not have any control over what is md5summed and where in the rendering chain changes to the page's appearance and functionality are actually made.
Current e-mail encryption is putting an additional load on the user. The user has to care about security at all, the user has to care about key management and trust settings, the user has to remember cryptography every time it is used.
If encryption ought to be used by mom and dad, and aunt Lucy, it has to be as easy to use as unencrypted e-mail. No additional mouse click, no additional message, no additional thinking. The sender's e-mail software determines whether the recipient is capable of receiving encrypted e-mail, retrieves keys if necessary, and encrypts messages whenever possible. If encryption is not possible, the message is sent in clear automatically. All this has to work without any specific setup phase right out of the box.
Given those side conditions it will be really hard to provide even a basic level of security. Encryption invisible to the user is prone to all kinds of attacks cryptographers hope to be prevented by sufficiently paranoid users. But the general user is neither paranoid nor an educated cryptographer, and won't be able to make the right decision either. Mom and dad don't know about certificates, man-in-the-middle-attacks and stuff like that. They never will.
When bringing cryptography to the masses we have to leave the ideal world of Alice, Bob and Mallory. We have to sacrifice perfect security for usability, and focus on solutions which are good enough instead of provably secure. We may also exchange security for detectability to a certain degree, like suggested in another message around here. Where we cannot prevent them from snooping, we could at least try to make them make noise when snooping.
Before you start your protest: How many web sites "just know you" because your identity is stored in a cookie or in a bookmark? If the answer is none, how do you handle all those user names passwords? How many well-chosen distinguished passwords do you use? On how many sites? How often are they changed? Did you ever use the Please e-mail me my password again function on any site? Did you ever write down a password?
In other words: Are you, the software developer, the perfectly secure person you suppose the average user to be?
Where do you see a new form of currency here? Do you consider tickets of all kinds, calling cards, or special rate telephone numbers as new froms of currency as well?
A lot of micropayment schemes had been proposed in the past. This one might work. Its inventors did not think about absolute security or cool cryptographic stuff. They thought about users and practicability.
The resulting scheme has several interesting properties:
Ok, usage could be even more easy, but at least it is no more difficult or inconvenient than using a credit card. A payment scheme for online digital goods and services requires convenience close to invisibility.
The card does not require software installation, prior registration of the user, or sophisticated authorization procedures. Just get a card and use it, that's all.
None of the many questions Joe Customer may possibly ask about a micropayment scheme has to be answered by using vocabulary from computer science or mathematics, or Alice-and-Bob-and-Mallory stories.
There is no way a customer could lose more money than his card is worth at the moment -- and mom and dad can actually understand why. The scheme also allows for exclusion of fraudulent merchants.
The card is bought anonymously. Payments made with the same card can be linked, but as long as none of the payments is linked to a person, those data are virtually useless. In typical micropayment situations, there is no need to ask the customer for his name. There is even a strong contraindication against any avoidable hassle. If a single card can be linked to a person, this relationship expires together with the card.
It can be used from any computer. No digital wallet, card reader, or other special equipment is needed. The customer doesn't need a computer at all. The scheme also works via WAP, SMS, or voice channels.
The most expensive thing probably is producing and distributing the cards. Anything else is handled by a computer somewhere on the net keeping a card numbers database and a merchants database and updating both if a transaction occurs.
I feel this is the best micropayment scheme ever designed. It just looks like user-centered design and a good-enough-approach. There is however one thing that could turn it into another failure: lack of acceptance on the Net. In order to become a real success it has to be accepted by sites throughout the universe. Limited to .de it would be pretty useless.
Even open source developers don't live from air and water alone, and not all of them can make a living from doing things connected to open source. So give it a try.
Make sure the conditions are clear to both sides. Leave them enough time and freedom to continue their open source activities besides the job. Think about non-traditional contracts, which might for example leave the opportunity to re-use code under an open source license after a well-defined period of commercial exploitation under closed source conditions. Let them use open source tools thery are used to as far as possible without getting into license conflicts with your own stuff. Be honest. Provide them with good working conditions.
Good luck.
Mainstream media are not particularly bright at computer stuff. They confused 'being a platform for mobile agents' with 'having viral problems'. And you do, too.
Web servants work in a stateless way.
Mundie tells us about research, inventions, intellectual property, and products, so let's question his words from a scientist's point of view. What, does he think, would a scientist prefer for her ideas? To sell them to $BIG_BUSINESS and risk them being thrown away for irrational reasons by suits who don't even understand them? It is a well-know fact that those who can afford it sometimes buy an idea just to make it vanish. Or would a scientist rather like the results and ideas to be implemented?
All those open source software developers actually implement ideas. No one requires Microsoft to pay them for it. They'll find their individual ways to make a living with or in spite of developing open source software. So what exactly is this guy talking about?
By the way, as Heise (in German) reports, The Royal Society has recently elected Tim Berners-Lee as a fellow for his work regarding the Web.
On page 180 of Raskin's book you will find a case study showing this is not necessarily true. Raskin's example is about saving workplace state to a floppy disk, and he had the same considerations about modes. After describing a one-button solution, he concludes that the modality in this situation depends on the user's model.
Applied to the remote control: If one thinks of an on function and an off function behind the same button, there are modes. But if we watch it as, for example, a general "change actrivity state" function (in Raskin's book it's a "do the right thing with the disk" function), there are no modes.
I don't think right and wrong are adequate categories here. In my opinion, the main problems in interface design are: there are not strict, absolute rules, and there are so many rules and trade-offs. As a result, most interfaces are a compromise between all those rules; they have to be. The interface designer's job is a multi-dimensional optimization problem.
Take colors for example. Designing a color scheme is a really hard task. One has to watch kind of side-effects, like brightness and contrast. One has to consider the possibility of color-blind users. Some combinations of colors strongly suggest a metaphor to the user, and should not be used if this is not intended; this applies namely to red-yellow-green which is likely to be associated with traffic lights -- in the western world. So cultural differences have to be taken into consideration, too.
Software developers tend to simplify and generalize the rules. That's what they are used to from programming. And they are seeking for recipes, for patterns. But there are no recipes and not many patterns for designing the user interfaces of sophisticated applications. Interface design needs skill, experience, the ability to watch your own creation with another one's eyes, and a will of iron to take every single problem of one's trial users seriously. And, of course, managers who do not sacrifice usability to deadlines and project plans.
The bad thing about vi is: once you learned it, you have to stick with it, because most other text editors will swallow your escapes and let the commands go through into the text.
ZZ
Too bad we don't have an Echelon system.
If not, why are crazy parents putting children in the age of four in front of their mast^H^H^H^Hcomputers then?
Working in the field of human factors, I fully agree with you in that it is the machines', or better the designers' and developers', fault if people encounter difficulties. Every careful reader of Don Norman's The Design of Everyday Things oder Jakob Nielsen's Alertbox column knows that.
The interesting thing is, most people don't. They surely notice when getting confused by some software, web site, or gadget, but they are drawing the wrong conclusion that they had to learn how to use it, or that their children should learn it as early as possible, and things like that. Just a few hours ago I encountered a colleague who complained about usability of some web site. It took me a while to assure her there really are incompetent "web designers" who do not care about users and do not really understand the concepts behind web technology. And this happens over and over.
And things are getting worse. The Internet not only brought to us a lot of incompetence in user interface design, but also a tendency to make three steps backwards unnecessarily. We are told the web browser will be the user interface for everything in the future, because "everyone can use a browser" (how about the application inside the browser?), our personal computers get replaced by "thin clients", and typing on a mobile phone's tiny keypad is considered an adequate way of making payments. In short, we are going back to terminals and transactions, and beyond.
Even cool sites like /. are affected. I would prefer to type into a real text editor instead of this text entry box. I would like an auto-save function for everything I write built into my /. client, like the one in my favourite Usenet newsreader. I would really appreciate a more flexible, i.e. not page oriented, presentation of comments, which my favourite Usenet newsreader provides as well. Don't get me wrong; /. is quite usable if one considers the limited capabilities of a web browser. But those capabilities are not sufficient for most interactive applications.
Recommended reading:
C. Fellenz, J. Parkkinen, H. Shubin: Resolving conflicts between the desktop and the Web
I guess a lawyer service watching all my communications and warning me about what may become illegal in the next seven years will be the long-searched killer application for next generation (i.e. UMTS) mobile networks.
Perhaps the first feminist campaign against digital pr0n? There actually has been one in Germany, back when the Internet still had been used mainly by academics.
Seriously, I believe it started when major newspapers began writing about it. You cannot tie it to a specific date. Since newspapers tend to copy from each other, only a small number of original articles was needed to spread the information that there is a thing called Internet. The technology had been available for years before, as well as access to online services, e.g. through Compuserve or local BBSs. Personally, I found the Internet attached to the back side of my first Unix account at the university back in '92.
Oh, and there was all that Information Superhighway babble from politicians. They still don't understand the Net, but they are doing a pretty good job telling everyone how to become a Super Couch Potato online.
That's bull^H^H^H^Han oversimplification. Though it is true that a command line interface is not appropriate for the average user, pure existence of a command line is by no means a sign of user-unfriendlyness. There is not even a contradistinction between command oriented user interfaces and graphical ones. The paradigm of graphical user intarfaces rather includes all the less powerful paradigms invented before, e.g. command oriented, forms based, and menu based interaction, and adds further means of expression (direct manipulation, visual affordances, etc.) for the designer as well as for the user.
This is the major reason why GUIs survived for 20 years -- they do not inhibit experienced users by forcing them into newbie-style interaction, but provide expert-friendly interfaces which are learnable to newbies; at least the better ones do. And there is the only flaw of command line interfaces: they require a huge amount of learning and don't help the user with it.
Oh, by the way, the Windows 2000 thing that came with my laptop computer has a command line, too. Are there people who do not use it because of that?
I would expect Microsoft to employ proprietary strategies, or at least slightly incompatible ones.