I REALLY hope the Starcraft 2 will be a classic strategy game. Not some freaking MMOG that you can only enjoy if you are willing to spend all your spare time playing it online with a bunch of other people equally willing to waste their lives away.
Indeed, RTS games are good because they have relatively short lived sessions with clear breaks to prompt one to actually getting up an do something else. That isn't to say that you couldn't just sit down and play one match after another... but at least there are breaks.
That said, I found that I can't get into highly competative online games simply because I don't spend all my spare time playing. When I do go to play such a game, I get my ass kicked by people who've perfected every strategy and counter-strategy known to man. I've gone back to playing single player games. I just can't take the online pressure anymore.
There's only so much WoW you can play before the game just gets boring. Adding new content doesn't fix that - you haven't really changed the game at all. It's like adding new tracks or courses to a racing game: nice, but, at the end of the day, I'm still going to go play something else.
This idea that WoW gets boring (never played it myself) intrigues me. On one hand you have people are have only barely broken an addiction to the game. And on the other people who complain that it gets boring. It seems like what you're really asking for is a game that make true addicts out of just about every player. Is that what you really want?
I hope it's more innovative than yet another RTS. I'm getting awfully bored with micromanage/clickfest games from Blizzard.
One thing in particular that always annoyed me was that you have to remember to go trhough your buildings and click "upgrade" periodically. It is like they ran out of ideas for keeping the player engaged and decide to add a bunch of extra unit upgrades that you have to remember to keep up on.
Research has "shown" no such thing. Asking me to believe that it has "shown" that is asking me to believe that any current finding is representative of all future findings. Fact is though, I don't believe research has even shown that with the current population.
Well, I was going to link to the research, but I guess there is no point. Apparently the people you know and your anecdotal evidence is far more reliable.
As I said before, I know lots and lots of people (by far the most of them!) that have their material needs basically entirely met; they have some things they would "like," but are hardly bitter about not having them. Would it be grand to live in a 10,000 sq foot mansion? Certainly. Am I bitter about not having it? Not at all. You?
It is much more subtle than that.
But let's take this further. Imagine a future day in which _everyone_ is effectively "the idle rich". I don't know how such a society could come to exist, where no one had to provide labor, but somehow everything still functioned, but supposing for a moment that such a society could exist, I'm incredulous that the "poor" (cough!) would rebel against the upper classes with their material needs so very well met.
I'm not talking about violent class conflict or some other uprising of the underprivilged. I'm just talking about happiness and how people of various income levels report it and how, as the per capital wealth of the population has increased, general happiness has not.
Research has shown that there is no satisfaction point when it comes to material wealth. Capitalism creates an environment where luxuries become necessities and new luxuries are sought (or rather, pushed by marketing and advertising) which in turn become necessities. What happens as you get a larger gap between rich and poor is that the poor become increasingly "jealous" (if the is the right word) of those on top. Consumers are constantly bombarded by images of the things they suppposed need but can't afford. This does not create happy people, to say the least.
BSD just isn't significantly different than Linux from a desktop user's perspective, thats all. I mean, KDE is KDE and GNOME is GNOME whether they are running on top of Linux or BSD.
I dunno. A bad movie is a bad movie. Maybe you mean "sit through" instead of "enjoy." The difference is that a bad game would consume much more time given the chance.
-matthew
Re:Why is it so hard to make a good Star Trek game
on
Star Trek Legacy Review
·
· Score: 4, Funny
Ok, but that is a pretty special case. We're talking about things like Netzero dialup accounts, dating sites, that kind of thing. You're talking about professional services that offer a wide range of options and control. Hell, do many ISPs even offer shell/web accounts anymore? In most cases it really is just a matter of disabling login.
You're missing his point, I think. Yes, a request is a request, but where a conventional webapp makes a single request to load the page, some AJAX webapps will make several. It's a sign of badly written apps more than of weakness in the AJAX concept, but a quite a few of them end up replacing one large request-response with many smaller ones.
Sorry, but there isn't going to be any meaningful discussion here until you decide to be more specific about what "some AJAX webapps" are. I'll admit that I rejected Yahoo's new beta email client because it is slow and cumbersome. In general I am against webapps that try to mimic the desktop experience with massive amounts of javascript running the the browser. But I've also seen AJAX implemented quite well. I've even implemented it myself. There are some really cool things you can do with AJAX that are totally worth it such as auto_complete fields and drag/drop and sorting lists.
The real problem is that HTML royally blows when it come to building rich UIs. It isn't necessarily AJAX that is the problem, it is all the hacks required to make rich GUIs out of HTML/CSS.
n theory it is "easier" on the server. But what we actually find is that the overhead of the requests can be greater.
Now you're really showing your ignorance. A GET request is a GET request.
This happens when too many AJAX requests are made to generate a page.
It depends on the framework, of course, but usually the initial page is generated through normal means. At least that is how AJAX works when using Ruby on Rails.
Soon the overhead of the request made by each individual AJAX request, plus the XML processing on the server-side, end up consuming more CPU and RAM than would be consumed had a typical CGI, PHP, JSP, etc., script been run.
How is processing XML any more intensive than processing HTML? And why do you keep making some distinction between CGI and AJAX?
I could have been more clear here. The existing system is basically a number of CGI scripts written in Perl. A request is made, the script is executed, the full page is generated, the full page is sent to the client, the script is terminated.
As opposed to an AJAX request being made, the script is executed, some XML is generated (less than the size of a full page), and the scrpt is terminated. Now what makes them so fundametally different?
What we're comparing is, in this instance, two Webmail applications. One is implemented as a number of Perl-based CGI scripts. The other is written using AJAX. The functionality being tested is equivalent in both, for the most part. The AJAX script does some work on the client-side which is just not necessary with the Perl CGI scripts, as would be expected.
There is no such thing as an "AJAX script." You're talking about AJAX as if it were a language. It is not. You're not making meaningful comparisons.
And what we find is that the Perl-based system is far more efficient, even if it is generating an entire page for each request. We have been successfully running it on what is today considered rather ancient hardware: two 200 MHz Pentium systems, with 128 MB of RAM in each. Yet the AJAX implementation, running on an extremely powerful quad-core Opteron system with 8 GB of RAM, couldn't handle as many concurrent clients as our Perl-based CGI system could. Even with the AJAX application vendor's help we only managed to get the AJAX system to handle 90% of the load of the existing Perl-based system.
Why is it that you can't seem to be more specific about this "AJAX system?" Not once have you actualy described its real architecture. What was the backend written in? Why did you see fit to "upgrade" your apparently awesome perl based system in teh first place? Clearly something was lacking.
Really, I don't care if you think I'm full of shit. What I can tell you is that I have tried the technology you support,
You have no idea what I "support," coward.
and I found it to be nonsense.
Like your posts.
and it seems that developers, even highly talented ones, are unable to develop quality software using it.
I dunno. People seem to like Gmail a lot.
Blab about the "greatness" of AJAX all you want. Those of us who have actually tried it know how much of a failure it is. We'll continue to use techniques and technology that actually works, while talking heads like yourself advocate AJAX and other fecal technologies that just can't carry their weight. Have yourself a good day, sir.
You're confusing the AJAX protocol with a complete AJAX application. I'm talking about complete applications, involving both the client-side and the server-side. After all, a protocol is pretty useless unless there are applications involved making use of that protocol.
The only difference in an "ajax applicaiton" as far as the server is concerned is that it renders XML rather than HTML. Otherwise, a GET request is a GET request.
Excuse me? AJAX is intimately involved with server-side technology. After all, there has to be some recipient on the server-side to respond to the AJAX requests sent by the client's Web browser. You can rarely build a useful AJAX application without involving a server of some sort. When designing an AJAX application, one must take into account server resource usage. Unfortunately, it often proves to be greater than when one is using a more traditional Web application development approach, including CGI scripts, PHP, JSP, etc.
You do understand that you can use CGI, PHP, JSP, etc to implement the server side of an AJAX web app, don't you? What else would you use?
Again, you're confusing protocol with applications. We're talking about AJAX applications here, many of which do end up using JavaScript to mess around with UI elements. This often leads to non-standard behavior which confuses users to no end.
An example?
Between the 9 of us, we have around 95 years of Web development experience. We know what we're doing.
If you think that "CGI, PHP, JSP, etc" are are entirely different than and opposed to "AJAX" then you clearly don't know what your doing. What do you think is responding to requests on the server side in an "AJAX application?" Do you not realize that one could easily use PHP, CGI (perl, ruby, etc), or Java to respond to AJAX requests?
And we can also identify poor technology, AJAX being the latest example. Had you read my post, you would have read that we even worked with the vendor of one of these commercial products to improve its performance with our installation (to no avail, I may add). I'd like to name names, but I don't think I'm in the position to do so right now.
You're posting as AC. What better position could there be to post such information?
On the server-side, they'd again result in excessive CPU and RAM consumption.
I'm going to call bullshit here. An ajax application is not significantly different on the server side than a regular web app. In fact, it is often easier on the server because the server only needs to render a small portion of the result for a given action rather than and entirely new page.
The Perl-based system was on a couple of 200 MHz Pentium systems, each with 128 MB of RAM. Even after assistance from the AJAX-based Webmail system's vendor, we were only able to handle roughly 90% of the number of transactions of our older system.
What does "perl based" have to do with it? You could very well have a Perl based (on the server side) AJAXy application.
All of our AJAX trials were abysmal failures. That's why we're sticking with the existing Perl- and Java-based systems that we currently use.
Bullshit again. You are comparing AJAX with Perl/Java based systems as if there was any comparison to be made. Saying Perl based systems are better than AJAX systems is like saying roads are better than cars!
The problem with getting rid of the file concept is that people need to preserve snapshots of documents, work on alternative copies, work speculatively forward from a checkpoint, look for documents by name or content, dispose of things that are no longer needed (and are just in the way), etc. Snapshotting named versions of a document is a simple way of accomplishing these things for which no reasonable alternative has been proposed that I know of -- and right there you already have most of the complexity of the file concept.
I dont' think most people work on documents like that. For the vast majority, they just make edits here and there on the same document. I'd never suggest taking away the possibility of "Save As..." (snapshot), I'm just suggesting that, by deafult, perhaps requiring a save isn't necessary and needlessly provides an opportunity for data loss. So we get extra options like "autosave" to make up for the fact that a lot of people still don't save regularly on their own. But then you get into situations that go something like: "What!? You didn't turn on autosave? You're screwed..."
Anyway, I was mostly just countering the "That is how it has always been done, people need to learn to do it that way!" sentiment.
I don't claim that there is no possible alternative to the file concept, but simply "sheltering" users from its complexity would force them to reinvent most or all of the complexity via onerous workarounds that might not transfer from one application to the next.
We already get workarounds like "autosave."
For example, you can simplify the "stapler system" by doing away with the stapler and letting the user apply the staples manually -- no more jams, no more refilling, no more moving parts -- but the user's life is simpler when using the more complex system.
That is not where I'm headed at all with this. Obviously the person wants/needs a tool to do the stapling for them. The idea is to make the functionality straight forward and make the device as "fool proof" as possible. Taking it away is just dumb and is nothing like what I am suggesting. What I am talking about is givng a user a stapler that just does one thing really well to replace a complex device that tries to do a lot of other things because someone, somewhere requested the features. We'll call it "feature creep." Modern software is FULL of it.
Anyway, the optimal solution can only be arrived at by experimentation. There are no general principles -- general principles tend to drive designs to unusable extremes like extreme orthogonality or extreme complexity.
I disagree I think simplicity (Keep It Simple, Stupid) is a good general principle. Complexity is the exception to the principle. That is, there is usually only a small minority who actually require great complexity and feature creep. These people should be using entirely different tools designed for people with complex needs. Unfortunately, software companies like Microsoft find it much more efficient to sell the same bloated product to everyone whether they'll actually use more than 10% of the features or not They try to make it look like they are selling a different product for different needs with tiered licensing models, but you and I both know that it (Vista, for example) is just the same damn bloated product with a couple switches turned on and off depending on how much the customer is willing to pay.
An "optimal" solution sounds like a "one sized fits all" solution and I just don't think that is a wise approach.
I think you're going in the wrong direction slightly, though I agree with your point. There's no reason to expect or hope for users to get more familiar with the internal complexities of either computers or cars. What would be great is for them to get better (more savvy) about *using* those things. And if we go to the cars well again, what do we see? Are drivers a lot more skilled than they were 50 years ago? Do they maintain safe following distance? Have any clue at all what their vehicles are capable of in an emergency? Do they use their fricking turn signals every once in a while? Obviously not. What bearing does that have on computers? I'm hoping not much, otherwise in 50 years users will be just as clueless as they are now.
I think it has a lot of bearing. I see a lot in common between the automobile of the past and computers today.
Keep in mind that despite users cluelessness about automobiles, they (cars) are a LOT safer than they were 50 years ago. So there is hope in that regard...
I think OS X might also be lacking somewhat on the enterprise management side. Despite using LDAP for OpenDirectory, it is still more like NT domains. For example, Workgroup Manager just displays a flat list of users/groups. It doesn't take advantage of the hierarchal nature of LDAP. And AFAIK you can to fancy things like partitioning your tree or doing that forest/tree thing that ActiveDirectory does (I'm an old Novel NDS/eDirectory guy, I'm not too familiar with the details of ActiveDirectory) You also have less control over users. I'd hate to deploy OpenDirectory in a very large org. OS X is still workgroup/education class, IMO. Hopefully Apple is adding more Enterprisey management features to Leopard.
The real question is how much sophistication can be reasonably expected from lifelong computer users. The file concept and needing to save one's work is an example of something that we've accepted that everyone can and should learn, in spite of the dire predictions of UI experts.
Ah, but couldn't you make a system that simply saved changes in realtime? Why should we expect users to save their work? Is it just the principle of the matter? Is saving work some kind of fundamental lesson, without which users would become lazy or complacent or something?
The idea that people would be better off sheltered from the file concept is, in retrospect, pretty silly -- as silly as the idea of equipping an automobiles with reins and a whip so it would feel like a horse-drawn carriage.
Automatic transmissions have sheltered people from having to worry about specific gears. Why not shelter computer users from worry about specific files?
I think we should stop projecting limitations onto humanity and see what happens.
The bottom line is that most people simply don't care about the underlying complexities of computers or automobiles. It isn't laziness. And it isn't necessarily a limitation on their part. They just don't care. Computers just don't interest most people like they might interest you or I. So if there are unnecessary complexities in an interface, I say take them out. If people can find 90% of what they want on the internet, for example, with a single Google input box, that is ideal. It would be counterproductive to present each user, by default, with a complex "advanced" search form just because it might make searches slightly more effective.
The typical "poor ignorant user" of 2030 is going to be at least as savvy as today's typical middle-class college student, and maybe more savvy in ways that surprise us.
I think it will surprise you. Going back to the car analogy... think of how "savvy" people have gotten with cars. They know all the brands. Have some idea of different fuel types. They know the difference between an SUV, a sedan, etc. But you know what? After 100 years of automobiles, the vast majority STILL don't understand any of the internal complexities. And in manys they know even less because cars today are generally so reliable (relatively speaking) there is little reason to even open the hood.
I think in 2030users will be savvy in the sense that they are savvy with automobiles today. They'll know how integrate computers into their lives and even do some very basic maintenance, but I am willing to bet that they won't be any more knowlegable, on average, of the internal complexities of computers than they are today. Remember, savvy does not mean "highly technical knowledge." It just means that you know the ins and outs of daily use without much hassle.
Yeah, I would have tried that except that I live in an apartment and can't disconnect the the system at the junction box. Also, I'd heard that you are not supposed to run many phones off of one ATA. I assume because of power draw or some such, but I never verified it.
In any case, I prefer cordless phones. So I might as well get a set of them.
Oh, i think we're past the early adopter stage of VoIP. By now it is pretty mature. I've been using VoIP for a couple years. I save a lot of money on my phone bill. What exactly are you waiting for?
The ONLY practical difference between my VoIP service and POTS is that I only have a single port for my POTS phone to plug into. I can't run telephone line everywhere. But that is easily solved by getting a set of cordless phones that all share a common base.
Indeed, it is pretty safe to assume that malicious groups either know about exploits BEFORE they are publicly posted or they know about exploits that the vendor doesn't. I mean, there is no reason to believe that only the "good guys" are discovering flaws. If I were a Black Hat, I wouldn't publicly release the exploits I knew about. I would try to keep them underground as long as possible so as to maximize their useful life.
And most of the people who mind would just block the ads anyway. I even block GoogleAds. I don't need to see ANY of it.
The real issue regarding sponsorship is how it might affect content. It would suck to have certain content removed if a sponsor didn't like it. Or maybe sponsors would get special privilege/priority to edit articles in their favor.
AJAX is complicated by the fact that you are executing code in two places... the server and the client. And code is often mixed with HTML. How obfuscated it is (or seems) really depends on the framework you are using. If you're putting together an app/site with PHP and writing your own AJAX calls, it can get pretty hairy. But when using something like Ruby on Rails, it is pretty straight forward.
Slashdot Mirror
Indeed, RTS games are good because they have relatively short lived sessions with clear breaks to prompt one to actually getting up an do something else. That isn't to say that you couldn't just sit down and play one match after another... but at least there are breaks.
That said, I found that I can't get into highly competative online games simply because I don't spend all my spare time playing. When I do go to play such a game, I get my ass kicked by people who've perfected every strategy and counter-strategy known to man. I've gone back to playing single player games. I just can't take the online pressure anymore.
-matthew
This idea that WoW gets boring (never played it myself) intrigues me. On one hand you have people are have only barely broken an addiction to the game. And on the other people who complain that it gets boring. It seems like what you're really asking for is a game that make true addicts out of just about every player. Is that what you really want?
-matthew
One thing in particular that always annoyed me was that you have to remember to go trhough your buildings and click "upgrade" periodically. It is like they ran out of ideas for keeping the player engaged and decide to add a bunch of extra unit upgrades that you have to remember to keep up on.
-matthew
Well, I was going to link to the research, but I guess there is no point. Apparently the people you know and your anecdotal evidence is far more reliable.
It is much more subtle than that.
I'm not talking about violent class conflict or some other uprising of the underprivilged. I'm just talking about happiness and how people of various income levels report it and how, as the per capital wealth of the population has increased, general happiness has not.
-matthew
Research has shown that there is no satisfaction point when it comes to material wealth. Capitalism creates an environment where luxuries become necessities and new luxuries are sought (or rather, pushed by marketing and advertising) which in turn become necessities. What happens as you get a larger gap between rich and poor is that the poor become increasingly "jealous" (if the is the right word) of those on top. Consumers are constantly bombarded by images of the things they suppposed need but can't afford. This does not create happy people, to say the least.
-matthew
BSD just isn't significantly different than Linux from a desktop user's perspective, thats all. I mean, KDE is KDE and GNOME is GNOME whether they are running on top of Linux or BSD.
-matthew
I dunno. A bad movie is a bad movie. Maybe you mean "sit through" instead of "enjoy." The difference is that a bad game would consume much more time given the chance.
-matthew
I imagine it is a lot like making a good movie.
Ok, but that is a pretty special case. We're talking about things like Netzero dialup accounts, dating sites, that kind of thing. You're talking about professional services that offer a wide range of options and control. Hell, do many ISPs even offer shell/web accounts anymore? In most cases it really is just a matter of disabling login.
-matthew
Sorry, but there isn't going to be any meaningful discussion here until you decide to be more specific about what "some AJAX webapps" are. I'll admit that I rejected Yahoo's new beta email client because it is slow and cumbersome. In general I am against webapps that try to mimic the desktop experience with massive amounts of javascript running the the browser. But I've also seen AJAX implemented quite well. I've even implemented it myself. There are some really cool things you can do with AJAX that are totally worth it such as auto_complete fields and drag/drop and sorting lists.
The real problem is that HTML royally blows when it come to building rich UIs. It isn't necessarily AJAX that is the problem, it is all the hacks required to make rich GUIs out of HTML/CSS.
-matthew
Not one by name. Sorry, I but I detect a troll.
-matthew
Now you're really showing your ignorance. A GET request is a GET request.
It depends on the framework, of course, but usually the initial page is generated through normal means. At least that is how AJAX works when using Ruby on Rails.
How is processing XML any more intensive than processing HTML? And why do you keep making some distinction between CGI and AJAX?
As opposed to an AJAX request being made, the script is executed, some XML is generated (less than the size of a full page), and the scrpt is terminated. Now what makes them so fundametally different?
There is no such thing as an "AJAX script." You're talking about AJAX as if it were a language. It is not. You're not making meaningful comparisons.
Why is it that you can't seem to be more specific about this "AJAX system?" Not once have you actualy described its real architecture. What was the backend written in? Why did you see fit to "upgrade" your apparently awesome perl based system in teh first place? Clearly something was lacking.
You have no idea what I "support," coward.
Like your posts.
I dunno. People seem to like Gmail a lot.
Talking head??? ROFL!
-matthew
The only difference in an "ajax applicaiton" as far as the server is concerned is that it renders XML rather than HTML. Otherwise, a GET request is a GET request.
You do understand that you can use CGI, PHP, JSP, etc to implement the server side of an AJAX web app, don't you? What else would you use?
An example?
If you think that "CGI, PHP, JSP, etc" are are entirely different than and opposed to "AJAX" then you clearly don't know what your doing. What do you think is responding to requests on the server side in an "AJAX application?" Do you not realize that one could easily use PHP, CGI (perl, ruby, etc), or Java to respond to AJAX requests?
You're posting as AC. What better position could there be to post such information?
-matthew
I'm going to call bullshit here. An ajax application is not significantly different on the server side than a regular web app. In fact, it is often easier on the server because the server only needs to render a small portion of the result for a given action rather than and entirely new page.
What does "perl based" have to do with it? You could very well have a Perl based (on the server side) AJAXy application.
Bullshit again. You are comparing AJAX with Perl/Java based systems as if there was any comparison to be made. Saying Perl based systems are better than AJAX systems is like saying roads are better than cars!
But thanks for you input anyway, Mr. Coward.
-matthew
I dont' think most people work on documents like that. For the vast majority, they just make edits here and there on the same document. I'd never suggest taking away the possibility of "Save As..." (snapshot), I'm just suggesting that, by deafult, perhaps requiring a save isn't necessary and needlessly provides an opportunity for data loss. So we get extra options like "autosave" to make up for the fact that a lot of people still don't save regularly on their own. But then you get into situations that go something like: "What!? You didn't turn on autosave? You're screwed..."
Anyway, I was mostly just countering the "That is how it has always been done, people need to learn to do it that way!" sentiment.
We already get workarounds like "autosave."
That is not where I'm headed at all with this. Obviously the person wants/needs a tool to do the stapling for them. The idea is to make the functionality straight forward and make the device as "fool proof" as possible. Taking it away is just dumb and is nothing like what I am suggesting. What I am talking about is givng a user a stapler that just does one thing really well to replace a complex device that tries to do a lot of other things because someone, somewhere requested the features. We'll call it "feature creep." Modern software is FULL of it.
I disagree I think simplicity (Keep It Simple, Stupid) is a good general principle. Complexity is the exception to the principle. That is, there is usually only a small minority who actually require great complexity and feature creep. These people should be using entirely different tools designed for people with complex needs. Unfortunately, software companies like Microsoft find it much more efficient to sell the same bloated product to everyone whether they'll actually use more than 10% of the features or not They try to make it look like they are selling a different product for different needs with tiered licensing models, but you and I both know that it (Vista, for example) is just the same damn bloated product with a couple switches turned on and off depending on how much the customer is willing to pay.
An "optimal" solution sounds like a "one sized fits all" solution and I just don't think that is a wise approach.
-matthew
I think it has a lot of bearing. I see a lot in common between the automobile of the past and computers today.
Keep in mind that despite users cluelessness about automobiles, they (cars) are a LOT safer than they were 50 years ago. So there is hope in that regard...
-matthew
I think OS X might also be lacking somewhat on the enterprise management side. Despite using LDAP for OpenDirectory, it is still more like NT domains. For example, Workgroup Manager just displays a flat list of users/groups. It doesn't take advantage of the hierarchal nature of LDAP. And AFAIK you can to fancy things like partitioning your tree or doing that forest/tree thing that ActiveDirectory does (I'm an old Novel NDS/eDirectory guy, I'm not too familiar with the details of ActiveDirectory) You also have less control over users. I'd hate to deploy OpenDirectory in a very large org. OS X is still workgroup/education class, IMO. Hopefully Apple is adding more Enterprisey management features to Leopard.
-matthew
Ah, but couldn't you make a system that simply saved changes in realtime? Why should we expect users to save their work? Is it just the principle of the matter? Is saving work some kind of fundamental lesson, without which users would become lazy or complacent or something?
Automatic transmissions have sheltered people from having to worry about specific gears. Why not shelter computer users from worry about specific files?
The bottom line is that most people simply don't care about the underlying complexities of computers or automobiles. It isn't laziness. And it isn't necessarily a limitation on their part. They just don't care. Computers just don't interest most people like they might interest you or I. So if there are unnecessary complexities in an interface, I say take them out. If people can find 90% of what they want on the internet, for example, with a single Google input box, that is ideal. It would be counterproductive to present each user, by default, with a complex "advanced" search form just because it might make searches slightly more effective.
I think it will surprise you. Going back to the car analogy... think of how "savvy" people have gotten with cars. They know all the brands. Have some idea of different fuel types. They know the difference between an SUV, a sedan, etc. But you know what? After 100 years of automobiles, the vast majority STILL don't understand any of the internal complexities. And in manys they know even less because cars today are generally so reliable (relatively speaking) there is little reason to even open the hood.
I think in 2030users will be savvy in the sense that they are savvy with automobiles today. They'll know how integrate computers into their lives and even do some very basic maintenance, but I am willing to bet that they won't be any more knowlegable, on average, of the internal complexities of computers than they are today. Remember, savvy does not mean "highly technical knowledge." It just means that you know the ins and outs of daily use without much hassle.
-matthew
Yeah, I would have tried that except that I live in an apartment and can't disconnect the the system at the junction box. Also, I'd heard that you are not supposed to run many phones off of one ATA. I assume because of power draw or some such, but I never verified it.
In any case, I prefer cordless phones. So I might as well get a set of them.
-matthew
Oh, i think we're past the early adopter stage of VoIP. By now it is pretty mature. I've been using VoIP for a couple years. I save a lot of money on my phone bill. What exactly are you waiting for?
The ONLY practical difference between my VoIP service and POTS is that I only have a single port for my POTS phone to plug into. I can't run telephone line everywhere. But that is easily solved by getting a set of cordless phones that all share a common base.
-matthew
Indeed, it is pretty safe to assume that malicious groups either know about exploits BEFORE they are publicly posted or they know about exploits that the vendor doesn't. I mean, there is no reason to believe that only the "good guys" are discovering flaws. If I were a Black Hat, I wouldn't publicly release the exploits I knew about. I would try to keep them underground as long as possible so as to maximize their useful life.
-matthew
The government is of/for the people, remember? In an indirect way, public property is MY property so I have some say. And I say keep the cameras out.
-matthew
And most of the people who mind would just block the ads anyway. I even block GoogleAds. I don't need to see ANY of it.
The real issue regarding sponsorship is how it might affect content. It would suck to have certain content removed if a sponsor didn't like it. Or maybe sponsors would get special privilege/priority to edit articles in their favor.
-matthew
I think a good obfuscated contest winner will go beyond mere syntactic scrambling. Or at least it would be "creative" syntactic scrambling.
Anyway, I HOPE you can't win the content simply by running normal code through an obfuscating program.
-matthew
AJAX is complicated by the fact that you are executing code in two places... the server and the client. And code is often mixed with HTML. How obfuscated it is (or seems) really depends on the framework you are using. If you're putting together an app/site with PHP and writing your own AJAX calls, it can get pretty hairy. But when using something like Ruby on Rails, it is pretty straight forward.
-matthew