Where in the U.S. did Dell recently build a Customer Contact Center?
- Roseburg, Oregon
- Oklahoma City, Oklahoma
- Edmonton, Alberta
- All of these
Monday, May 21, 2007
Fifty-four forty or fight!
Today I flunked this quiz question asked of registrants for a Dell sweepstakes:
Where in the U.S. did Dell recently build a Customer Contact Center?
Where in the U.S. did Dell recently build a Customer Contact Center?
Monday, May 07, 2007
And I had never heard of Doug Engelbart!
Since Reginald B. and Alan Kay have urged us to google Doug Engelbart, I reckoned it must be important, so I did. And I found this amazing demo from 1968 of, basically, my computer.
Friday, May 04, 2007
RIA Not Advancing the Ball
Rich widgets obscure the semantics of hypertext. Only the code behind the form knows what the widget really does. Contrast to HTML 5, and in particular Web Forms 2. These guys are extending HTML to capture what we really do on the web. As a consequence, client programs can (or, have a chance to) understand the meanings of hypertext documents from the web.
Example: you want to write a script to automate some remote bookmark service, as part of your mashup. But this service, unlike del.icio.us, has no documented "API". So you have to download its form, complete it programmatically, and POST an entity.
Case 1: The form uses Plain Old HTML. You're golden. All the semantics are right there for you to parse, or read. You identify the name of the text box where you stick the URL, and the name of the text box where you add a description. You compose the URL encoded form data, and POST it to the action URI.
Case 2: The "form" uses Javascript to modify the DOM on the fly: the onload() method adds text boxes, and a submit button, to an empty DOM. In fact, it might not even use the submit button as a form element; when you press the button, its onclick() might send a custom XMLHttpRequest back to the server. Your code will never automate this interaction.
Case 3: The "form" uses XAML + Silverlight plugin. An exacerbated case of (2).
In contrast, Web Forms 2 attempts to capture the semantics of what we do with forms. Because browsers will understand more of the semantics of the form, we can do declaratively what we now have to do in Javascript. For example, lots of HTML forms now have to use script to add a row of controls to a form on the fly ("Click here to add another bookmark"). WF2 captures that as repeating control groups, and the browser can handle it.
(Then again, I am a documented forms nut.)
Mike Dierken justly analogizes: "RIA is to user interfaces as RPC is to messaging interfaces". And notice, it's Rich Internet, not Rich Web Applications. These technologies pay lip service to the web, but they're not advancing the ball toward building more and better links throughout the web information space.
P.S. Wonderful rant by Mark Pilgrim!
Update: fixed a link.
Example: you want to write a script to automate some remote bookmark service, as part of your mashup. But this service, unlike del.icio.us, has no documented "API". So you have to download its form, complete it programmatically, and POST an entity.
Case 1: The form uses Plain Old HTML. You're golden. All the semantics are right there for you to parse, or read. You identify the name of the text box where you stick the URL, and the name of the text box where you add a description. You compose the URL encoded form data, and POST it to the action URI.
Case 2: The "form" uses Javascript to modify the DOM on the fly: the onload() method adds text boxes, and a submit button, to an empty DOM. In fact, it might not even use the submit button as a form element; when you press the button, its onclick() might send a custom XMLHttpRequest back to the server. Your code will never automate this interaction.
Case 3: The "form" uses XAML + Silverlight plugin. An exacerbated case of (2).
In contrast, Web Forms 2 attempts to capture the semantics of what we do with forms. Because browsers will understand more of the semantics of the form, we can do declaratively what we now have to do in Javascript. For example, lots of HTML forms now have to use script to add a row of controls to a form on the fly ("Click here to add another bookmark"). WF2 captures that as repeating control groups, and the browser can handle it.
(Then again, I am a documented forms nut.)
Mike Dierken justly analogizes: "RIA is to user interfaces as RPC is to messaging interfaces". And notice, it's Rich Internet, not Rich Web Applications. These technologies pay lip service to the web, but they're not advancing the ball toward building more and better links throughout the web information space.
P.S. Wonderful rant by Mark Pilgrim!
Update: fixed a link.
Thursday, May 03, 2007
RIA -- Fill 'er Up!
I'm having an ongoing email exchange with my friend Peter. He's convinced MS and Adobe herald a new age of Rich Internet Applications. He pointed me to this guy who's backed up a tanker to the Kool-Aid trough.
Sure, MS and Adobe have to sell something as the Next Thing -- what else have they got? But we've had RIA ever since Java 1.1 applets. We have Flash. We have <embed> and <object>. Do you really think what's been holding RIA back is the technology?
Users have voted with their mice, and they've voted for the web experience -- exploring the web information space using hyperlinks -- as far more important than whizzy UI. Ask eBay. Ask MySpace.
Flash, applets, Silverlight, Javascript -- the more you use them, the suckier your web apps are at exploring the web information space. I don't think it has to be this way, but it takes a design discipline few seem to have. These programming models are from the 80s. They have web APIs, but they're not web oriented. Programs end up as little desktop applications, not web apps. I don't see Silverlight changing that. It is good to have super expressive widgets -- hear hear. But if you're not pushing a bunch of hypertext down to my browser, you're not helping me explore the space.
Sure, MS and Adobe have to sell something as the Next Thing -- what else have they got? But we've had RIA ever since Java 1.1 applets. We have Flash. We have <embed> and <object>. Do you really think what's been holding RIA back is the technology?
Users have voted with their mice, and they've voted for the web experience -- exploring the web information space using hyperlinks -- as far more important than whizzy UI. Ask eBay. Ask MySpace.
Flash, applets, Silverlight, Javascript -- the more you use them, the suckier your web apps are at exploring the web information space. I don't think it has to be this way, but it takes a design discipline few seem to have. These programming models are from the 80s. They have web APIs, but they're not web oriented. Programs end up as little desktop applications, not web apps. I don't see Silverlight changing that. It is good to have super expressive widgets -- hear hear. But if you're not pushing a bunch of hypertext down to my browser, you're not helping me explore the space.
Subscribe to:
Posts (Atom)