Genuine risk-takers know setbacks are part of the creative process. Any innovator worthy of that name accepts that success is the exception, failure the rule. That’s why those who are too focused on succeeding can’t innovate.
The pressure to be a risk-taker, or even to appear to be a risk-taker while not actually taking any real risks, is at the root of innovation burnout, in my opinion. Here’s Keyes again:
How can that [failure-tolerant] mind-set be encouraged? When I ask business leaders, most say that they urge workers to take more risks. This approach seldom has the desired effect, and for good reason. ‘They tell us to take more risks,’ one middle manager told me, ‘but you’re expected never to fail.’
"It’s no surprise then that people jumped to RSS to control information flow. We are telling the creators of information that we want filters, we want flow control, and we want those controls in our own hands. It’s the era of syndication and subscriptions. I’ll tell you what information I want, and then you come find me with the right data in the right place at the right time."
If you don’t read Matt and you obsess about publishing models, then you’re missing one of the smartest voices out there.
This is an excellent demonstration of the power of AJAX coding for web services. (AJAX – for you sub-rock dwellers, is Asynchronous JavaScript and XML, and the au courant technology du jour of 2005).
Essentially, it’s an online dictionary that kicks the stuffing out of Dictionary.com. I stuck a quick launch link on my 11-year old son’s new laptop and within two days ObjectGraph passed the ultimate test when he said, "Dad, this dictionary thing rules."
So, next time you’re stuck trying to demo what Ajax is all about, and don’t want to quote the following explanation from the Wikipedia, show ’em Objectgraph:
From WikiPedia:
"Ajax applications look almost as if they reside on the user’s machine, rather than across the Internet on a server. The reason: pages get updated, not entirely refreshed.
“Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead”, wrote Jesse James Garrett, in the essay that first defined the term. “Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.”
Traditional web applications essentially submit forms, completed by a user, to a web server. The web server responds back by sending a new web page. Because the server must submit a new page each time, applications run more slowly and awkwardly than their native counterparts.
Ajax applications, on the other hand, can send requests to the web server to retrieve only the data that is needed, usually using SOAP or some other XML-based web services dialect. On the client, JavaScript processes the web server response. The result is a more responsive interface, since the amount of data interchanged between the web browser and web server is vastly reduced. Web server processing time is also saved, since much of it is done on the client."
