Preferences > privacy > history > [0] days; ok. Patched. I use the history feature about twice a year, won't miss it till the right fix is found. Not quite like disabling all the javascript in MSIE, is it?
130 pages. About 30 pages filled with equations. Lots of photos, figures, tables, listings, indexes etc. Pentium 4 3GHZ, 1GB RAM. Over a minute to load/save. During saves system slows down to a crawl, what you type appears some 10 seconds later. You just have to wait through. Thank you, I'd better decide when to save by myself. Give the systems another 10 years of Moore's law and we can talk about removing 'save' again.
Like most of modern cellular phones with voice dialling? Just press one button to call, say the name of the recipient (in your addressbook) and it dials automatically.
Undo is an entirely different functionality than browsing backward in a series of navigation steps. Not -entirely-. Somewhat different. Undo differs from app to app too. In some it takes back the last keystroke, in some the last paragraph. I know one where it just recovers the project template, discarding all the changes since last save (do I have to say how much it sucks?). In browsing, "back" moves by a single navigation unit, a page. It's the undo in context of plain HTML, not concerned with scripts, embeds, forms, redirects and other entities beyond the scope of normal webpage.
Using the back button as an undo event sink is a terrible idea IMO. As the lowest-level undo, like unclick a checkbox, reopen previously closed "image properties", yes. But in context of plain navigation, it IS an undo event sink.
Structured undo (as in Photoshop) is a great idea, but it should be implemented within the application. Sure. Rarely they implement -any- undo though, while breaking the simple pseudo-undo of a back button, so Ajax sucks most of the rest of the time. In browsers, you can skip multiple pages back already, and removing one older navigation step from the stack wouldn't make sense.
Again, I'd disagree. If a web page contains an application, I believe they should exist on separate layers. The application should be built within the browser space, but to a certain degree, maintain a layer of separation.
And here we agree. Webdesigners using Ajax mostly disagree with both of us though. If you make it an app, if you make it clear it's an app, not just a webpage, if you provide all the functionalities one would expect from an app, and preferably break as few functionalities of a webpage as you can, then your AJAX app won't suck. This is rarely the case though. Usually the random blend of an app and a webpage makes it extremely hard to distinguish, where you can use your webpage habits and where they are broken, whenever they are broken, rarely any app-level replacement is to be found, and while AJAX is an interesting tool that -can- make really good and interesting apps, currently wherever applied it usually sucks.
Tabs in the context of web pages already have an expected behavior. Tabs in the context of applicatios already have an expected behavior. Unfortunately, they are in conflict. When you click the back button, does Firefox take you to the previous tab (as in browser tab, not web page tab? I use the "go back to referrer" bookmarklet for that, and it doesn't switch tabs, but loads the page from which the tab was opened from, as an additional step of "back". I imagine the structure of navigation not as a timeline like in "history" but as a tree of pages being open in separate tabs, closed tabs being ends of the branches, pages open from bookmarks or typed in URLs as roots etc. I'd yet have to see a navigational interface to utilize this point of view.
Sure, you compare to thick clients, but how thick a client is a bunch of downloaded javascript?! That's not buying you anything.
Depends on the amount of Javascript. What is the thick client written in is an arbitrary decision. More "talking" than telnet/ssh (but these are text-only, thus unfashionable) but still way less than, say, VNC or X forwarding.
And don't underestimate Javascript. 1) Download sources of Firefox. Some 60% is written in JS. 2) Windows Explorer (not really MSIE), options, customize current directory - you suddenly find Notepad filled with a javascript app that does displaying the directory content. A serious part of Windows GUI is Javascript. It's WAY more than making pictures on webpages blink.
The rules are: Always validate on the server side to provide continuous service for -all- users, just by not getting hacked. Without that, you're screwed, simple. Validate on the client side to avoid having the client pissed off with waiting for an error message from the server. If you screw up validation on the client side, no biggie, the server WILL handle it. Just take care so that any screw-ups on the client side are directed to the permissive side, not the restrictive one. Nothing more pissing off than an overzealous javascript validator like "your postal code isn't 6-digit in xxx-xxx form" when all codes in your country are ALWAYS 5-digit in xx-xxx form, and you have already chosen the country on the country list. Or a better one: Name: second, first. Sorry, your second name must be at least 4 characters long.
True, one more point of development/maintenance, but non-essential one, feel free to put in low priority bin if you make disabling it easy.
Because MOST of the time you expect a browser to act as a browser and display webpages. When AJAX steps in, you don't always know about it or really want it, and then, when browser stops acting as a browser despite what you expect, it sucks all the way. I middle-click on each of the row of new messages in GMail to open them in new tabs, as I'm used to doing whenever I see a list of links I want to open, then it doesn't work. I need to use the sucky "newer/older" navigation, and wait for next message to load from the server (XMLHTTPReauest takes time too!) instead of having it already loaded in a new tab in the background.
When you expect an app to be running in your webbrowser, be that a flash site, a java applet, a javascript piece that obviously -is- an app, then you're prepared for your browser to behave differently. You're in a "different mode" and avoid some browser features because you know they won't work or will work not as normally. But Ajax integrates so seamlessly that it's often invisible, until you try to use your god-given rights to go a page back or open a link with middleclick and find yourself out in the cold. Then it really sucks.
As for the first point, trying it out and saying "no, it's too hard for me, I can't handle this" is one thing. Saying what I cited, that is refusing to try it and investigate it and plainly refusing the new(old?) (even if WAY easier and more handy) tech because it means learning two lines of commands is another.
Concerning your second point, already done. The bucket broke while trying to have sex with a high horse, lost my virginity to a pony mare. Really.
Sure, checking data before it is sent is nice but validating data is incorrect since that data can be changed without the script and sent to the server.
ALWAYS validate on the server side. Independently of any (if any) validation on the client side. Having the data sent from a script is actually nice: someone is integrating their apps with our services. Seems we should call the dev dept and tell them to hurry up with releasing the public API.
Can be avoided using the data: URL scheme for embedding content:)
BTW, how to convert a WHOLE page (including linked images) to a data: URL? (automatically, js preferred) Can you access the raw image data from inside javascript?
Yes, missing something. Serving a billion HTTP requests a day and performing maybe 1000 cycles of real CPU work on processing the data received besides all than TCP, HTTP, PHP etc overhead is nothing compared to running a billion apps locally and serving their gfx output over the net. Both in bandwidth and CPU usage meaning. Thick clients plus reducing throughtput to necessary minimum is way cheaper on the server side. No meaning if both client and server boxes (and net) are under common ownership. Essential if you pay for the server, your customers pay for the clients (and someone else gets the money for bandwidth from both of you).
Creating alternatives. Tags like NOSCRIPT, NOFRAMES come in mind. "Traditional" gmail interface that works in Lynx. Make AJAX provide all the handy, slick functionality but provide old-fashioned CGI-based alternatives.
we are suppposed to be critical of ajax because, wait for it... it makes the browser work like a standard application. huh? We are supposed to be critical of ajax because it makes browser stop working like a browser. If the application sucks, it sucks, we are critical of it, fine. Ajax or not. But we have certain expectations towards applications that -are- webpages. That is, that they behave -somewhat- like webpages. When they don't (and with Ajax, they usually don't), we start being critical of them... Ajax sucks MOST of the time. Not always.
store the variables into a cookie...Any gotchas here that I'm not thinking of? Cookie size. Instead, just create a hidden frame and store this all in RAM as javascript objects. Cookies are good just for surviving client crashes;)
OO Writer has no back button. Why? What is "back" in the context of authoring a document? "undo". It does have it. And it would suck without it. Unstructured Undo in Gimp is mentioned as one of its most serious weaknesses (as opposed to the one in Photoshop, where you can undo any previous step without affecting the ones that happened later)
Take Google maps for example. How does the back button affect the page when I have moved the map? How should it affect the page? Take you back in the history of your "map travels", say, one map drag, zoom click or search back. Obvious from user point of view. Helluva hard from programmer's point of view. Thanks to AJAX.
I want it to take me back to the previous navigable location. Previous seen email in GMail, previous seen location in Google Maps, previous config screen or any other perceivable previous navigation unit. AJAX blurs/removes them. Is the next tab of DeviantArt prefs a new page or not?
Application state and browser state can be separate and usable. Can be. But more often isn't than is.
Over the last decade, computers and networks have become much faster. 10 mbit ethernet, Athlon 2400, 1 gig of RAM, loading the ssh applet takes about two minutes. The computers still need another decade or so to make applets a viable option.
What is so wrong with saving application functionality for protocols designed to handle it like SSH and Telnet?
Idiots. Show one the black window of Telnet and tell to type 'pine' and they will freak out and cry 'i don't want it, I don't need it, I have my Hotmail account." Faced a few in my time, some calling themselves admins too.
Soon you'll get tired with in-game ads just the same as with the real-world ones. The novelty will end and the effectiveness will drop just to the standard low margins of all ads. You, Americans, were brought up in the world of commercials. I lived through fall of "communism" in Poland, and back then there was almost no commercials. And completely no TV commercials. When the first ones showed up on TV, it was all the craze. Everyone was buying the cockroach killer stickers, even if you had no cockroaches, just because it was on TV. Kids were crazy about the Kuku-Ruku candy bar, even if there were many better, tastier, cheaper ones in trade. But this one was in TV commercials. TV commercials were new and cool. Then they got boring and started to really piss people off. Just to the degree they do now.
That's the point. Theoretically everything should work just fine, but it shows that software developers just didn't imagine the scenario. The benchmarks show either performance of dual single-core, or single dual-core, or crash, and only on rare occasions performance better than any "lesser" config. It gives you little insight into the state of the PC in such config, and as such isn't really useful, you'd be stupid to use such an error-prone config anyway. But it gives a LOT of insight into the state of current software that claims to be utilizing multi-processor configs. That is, most of it is really poorly written and can't handle anything "non-standard" like 3 CPUs correctly.
That's the only point where it can't simulate "real world". It will rumble. That's all. And that's what I meant by "swordfight may suck". A tennis rocket makes contact with the ball for a fraction of second. The fishing rod, the throwing knife - no force feedback. Steering grip - very little feedback, road bumps etc. Gun - recoil at most. There is still no way to simulate the material resistance. Most likely it will be in the next Nintendo, a servo-rotated heavyweight gyroscope that makes turning it hard, when not allowed, would limit movement in the 3 rotary degrees of freedom. Still no idea how to limit movement.
It's most likely used for precise screen positioning - gun aiming. Method similar to light pen, or classic "optical pistols" used in video games. I DOES have "something in common" with positioning but it's just one of many positioning systems contained in the controller.
Yes, you should be more excited. Gyroscopes, accelerometers plus some kind of positioning system. Full six degrees of freedom at wide movement range and full 360 degrees rotation range. As opposed to classic joystick-like manipulator, with 2 degrees of freedom and maybe 30 degrees rotation range. That means the manipulator can act as: Knife, gun, pen, mouse, fishing rod, joystick, driving grip (motorbikes), tennis rocket, and mostly everything you hold in hand and move around, that doesn't give you important force feedback that can't be simulated with rumble. Possibly, as a sword it would suck, but it's possible to use as one too.
Slashdot Mirror
You're assumed to know some more names as well: Bill Gates, Lex Luthor, Steve Ballmer, Darl McBride, Dr. Evil, John C. Dvorak.
http://ask.slashdot.org/article.pl?sid=05/11/27/02 59249&tid=133&tid=4
stickers for ya.
http://www.railgun.org/
No updates since 2002.
Preferences > privacy > history > [0] days; ok.
Patched. I use the history feature about twice a year, won't miss it till the right fix is found.
Not quite like disabling all the javascript in MSIE, is it?
130 pages. About 30 pages filled with equations. Lots of photos, figures, tables, listings, indexes etc.
Pentium 4 3GHZ, 1GB RAM.
Over a minute to load/save. During saves system slows down to a crawl, what you type appears some 10 seconds later. You just have to wait through.
Thank you, I'd better decide when to save by myself. Give the systems another 10 years of Moore's law and we can talk about removing 'save' again.
Like most of modern cellular phones with voice dialling? Just press one button to call, say the name of the recipient (in your addressbook) and it dials automatically.
Undo is an entirely different functionality than browsing backward in a series of navigation steps.
Not -entirely-. Somewhat different. Undo differs from app to app too. In some it takes back the last keystroke, in some the last paragraph. I know one where it just recovers the project template, discarding all the changes since last save (do I have to say how much it sucks?). In browsing, "back" moves by a single navigation unit, a page. It's the undo in context of plain HTML, not concerned with scripts, embeds, forms, redirects and other entities beyond the scope of normal webpage.
Using the back button as an undo event sink is a terrible idea IMO.
As the lowest-level undo, like unclick a checkbox, reopen previously closed "image properties", yes. But in context of plain navigation, it IS an undo event sink.
Structured undo (as in Photoshop) is a great idea, but it should be implemented within the application.
Sure. Rarely they implement -any- undo though, while breaking the simple pseudo-undo of a back button, so Ajax sucks most of the rest of the time. In browsers, you can skip multiple pages back already, and removing one older navigation step from the stack wouldn't make sense.
Again, I'd disagree. If a web page contains an application, I believe they should exist on separate layers. The application should be built within the browser space, but to a certain degree, maintain a layer of separation.
And here we agree. Webdesigners using Ajax mostly disagree with both of us though. If you make it an app, if you make it clear it's an app, not just a webpage, if you provide all the functionalities one would expect from an app, and preferably break as few functionalities of a webpage as you can, then your AJAX app won't suck. This is rarely the case though. Usually the random blend of an app and a webpage makes it extremely hard to distinguish, where you can use your webpage habits and where they are broken, whenever they are broken, rarely any app-level replacement is to be found, and while AJAX is an interesting tool that -can- make really good and interesting apps, currently wherever applied it usually sucks.
Tabs in the context of web pages already have an expected behavior. Tabs in the context of applicatios already have an expected behavior. Unfortunately, they are in conflict. When you click the back button, does Firefox take you to the previous tab (as in browser tab, not web page tab?
I use the "go back to referrer" bookmarklet for that, and it doesn't switch tabs, but loads the page from which the tab was opened from, as an additional step of "back". I imagine the structure of navigation not as a timeline like in "history" but as a tree of pages being open in separate tabs, closed tabs being ends of the branches, pages open from bookmarks or typed in URLs as roots etc. I'd yet have to see a navigational interface to utilize this point of view.
Sure, you compare to thick clients, but how thick a client is a bunch of downloaded javascript?! That's not buying you anything.
Depends on the amount of Javascript. What is the thick client written in is an arbitrary decision. More "talking" than telnet/ssh (but these are text-only, thus unfashionable) but still way less than, say, VNC or X forwarding.
And don't underestimate Javascript. 1) Download sources of Firefox. Some 60% is written in JS. 2) Windows Explorer (not really MSIE), options, customize current directory - you suddenly find Notepad filled with a javascript app that does displaying the directory content. A serious part of Windows GUI is Javascript. It's WAY more than making pictures on webpages blink.
The rules are: Always validate on the server side to provide continuous service for -all- users, just by not getting hacked. Without that, you're screwed, simple. Validate on the client side to avoid having the client pissed off with waiting for an error message from the server. If you screw up validation on the client side, no biggie, the server WILL handle it. Just take care so that any screw-ups on the client side are directed to the permissive side, not the restrictive one. Nothing more pissing off than an overzealous javascript validator like "your postal code isn't 6-digit in xxx-xxx form" when all codes in your country are ALWAYS 5-digit in xx-xxx form, and you have already chosen the country on the country list. Or a better one: Name: second, first. Sorry, your second name must be at least 4 characters long.
True, one more point of development/maintenance, but non-essential one, feel free to put in low priority bin if you make disabling it easy.
Because MOST of the time you expect a browser to act as a browser and display webpages. When AJAX steps in, you don't always know about it or really want it, and then, when browser stops acting as a browser despite what you expect, it sucks all the way. I middle-click on each of the row of new messages in GMail to open them in new tabs, as I'm used to doing whenever I see a list of links I want to open, then it doesn't work. I need to use the sucky "newer/older" navigation, and wait for next message to load from the server (XMLHTTPReauest takes time too!) instead of having it already loaded in a new tab in the background.
When you expect an app to be running in your webbrowser, be that a flash site, a java applet, a javascript piece that obviously -is- an app, then you're prepared for your browser to behave differently. You're in a "different mode" and avoid some browser features because you know they won't work or will work not as normally. But Ajax integrates so seamlessly that it's often invisible, until you try to use your god-given rights to go a page back or open a link with middleclick and find yourself out in the cold. Then it really sucks.
As for the first point, trying it out and saying "no, it's too hard for me, I can't handle this" is one thing. Saying what I cited, that is refusing to try it and investigate it and plainly refusing the new(old?) (even if WAY easier and more handy) tech because it means learning two lines of commands is another.
Concerning your second point, already done. The bucket broke while trying to have sex with a high horse, lost my virginity to a pony mare. Really.
Sure, checking data before it is sent is nice but validating data is incorrect since that data can be changed without the script and sent to the server.
ALWAYS validate on the server side. Independently of any (if any) validation on the client side.
Having the data sent from a script is actually nice: someone is integrating their apps with our services. Seems we should call the dev dept and tell them to hurry up with releasing the public API.
Can be avoided using the data: URL scheme for embedding content :)
BTW, how to convert a WHOLE page (including linked images) to a data: URL? (automatically, js preferred)
Can you access the raw image data from inside javascript?
Yes, missing something.
Serving a billion HTTP requests a day and performing maybe 1000 cycles of real CPU work on processing the data received besides all than TCP, HTTP, PHP etc overhead is nothing compared to running a billion apps locally and serving their gfx output over the net. Both in bandwidth and CPU usage meaning. Thick clients plus reducing throughtput to necessary minimum is way cheaper on the server side. No meaning if both client and server boxes (and net) are under common ownership. Essential if you pay for the server, your customers pay for the clients (and someone else gets the money for bandwidth from both of you).
Creating alternatives. Tags like NOSCRIPT, NOFRAMES come in mind. "Traditional" gmail interface that works in Lynx. Make AJAX provide all the handy, slick functionality but provide old-fashioned CGI-based alternatives.
we are suppposed to be critical of ajax because, wait for it... it makes the browser work like a standard application. huh?
We are supposed to be critical of ajax because it makes browser stop working like a browser. If the application sucks, it sucks, we are critical of it, fine. Ajax or not. But we have certain expectations towards applications that -are- webpages. That is, that they behave -somewhat- like webpages. When they don't (and with Ajax, they usually don't), we start being critical of them...
Ajax sucks MOST of the time. Not always.
store the variables into a cookie...Any gotchas here that I'm not thinking of? ;)
Cookie size.
Instead, just create a hidden frame and store this all in RAM as javascript objects. Cookies are good just for surviving client crashes
OO Writer has no back button. Why? What is "back" in the context of authoring a document?
"undo". It does have it. And it would suck without it.
Unstructured Undo in Gimp is mentioned as one of its most serious weaknesses (as opposed to the one in Photoshop, where you can undo any previous step without affecting the ones that happened later)
Take Google maps for example. How does the back button affect the page when I have moved the map? How should it affect the page?
Take you back in the history of your "map travels", say, one map drag, zoom click or search back. Obvious from user point of view. Helluva hard from programmer's point of view. Thanks to AJAX.
I want it to take me back to the previous navigable location.
Previous seen email in GMail, previous seen location in Google Maps, previous config screen or any other perceivable previous navigation unit. AJAX blurs/removes them. Is the next tab of DeviantArt prefs a new page or not?
Application state and browser state can be separate and usable.
Can be. But more often isn't than is.
Over the last decade, computers and networks have become much faster.
10 mbit ethernet, Athlon 2400, 1 gig of RAM, loading the ssh applet takes about two minutes.
The computers still need another decade or so to make applets a viable option.
What is so wrong with saving application functionality for protocols designed to handle it like SSH and Telnet?
Idiots.
Show one the black window of Telnet and tell to type 'pine' and they will freak out and cry 'i don't want it, I don't need it, I have my Hotmail account." Faced a few in my time, some calling themselves admins too.
Soon you'll get tired with in-game ads just the same as with the real-world ones. The novelty will end and the effectiveness will drop just to the standard low margins of all ads.
You, Americans, were brought up in the world of commercials. I lived through fall of "communism" in Poland, and back then there was almost no commercials. And completely no TV commercials. When the first ones showed up on TV, it was all the craze. Everyone was buying the cockroach killer stickers, even if you had no cockroaches, just because it was on TV. Kids were crazy about the Kuku-Ruku candy bar, even if there were many better, tastier, cheaper ones in trade. But this one was in TV commercials. TV commercials were new and cool.
Then they got boring and started to really piss people off. Just to the degree they do now.
That's the point. Theoretically everything should work just fine, but it shows that software developers just didn't imagine the scenario. The benchmarks show either performance of dual single-core, or single dual-core, or crash, and only on rare occasions performance better than any "lesser" config. It gives you little insight into the state of the PC in such config, and as such isn't really useful, you'd be stupid to use such an error-prone config anyway. But it gives a LOT of insight into the state of current software that claims to be utilizing multi-processor configs. That is, most of it is really poorly written and can't handle anything "non-standard" like 3 CPUs correctly.
That's the only point where it can't simulate "real world".
It will rumble.
That's all.
And that's what I meant by "swordfight may suck".
A tennis rocket makes contact with the ball for a fraction of second.
The fishing rod, the throwing knife - no force feedback. Steering grip - very little feedback, road bumps etc. Gun - recoil at most.
There is still no way to simulate the material resistance. Most likely it will be in the next Nintendo, a servo-rotated heavyweight gyroscope that makes turning it hard, when not allowed, would limit movement in the 3 rotary degrees of freedom. Still no idea how to limit movement.
It's most likely used for precise screen positioning - gun aiming. Method similar to light pen, or classic "optical pistols" used in video games. I DOES have "something in common" with positioning but it's just one of many positioning systems contained in the controller.
Yes, you should be more excited. Gyroscopes, accelerometers plus some kind of positioning system. Full six degrees of freedom at wide movement range and full 360 degrees rotation range. As opposed to classic joystick-like manipulator, with 2 degrees of freedom and maybe 30 degrees rotation range.
That means the manipulator can act as: Knife, gun, pen, mouse, fishing rod, joystick, driving grip (motorbikes), tennis rocket, and mostly everything you hold in hand and move around, that doesn't give you important force feedback that can't be simulated with rumble. Possibly, as a sword it would suck, but it's possible to use as one too.