Ain't gonna happen. Or, if you prefer: Already happened.
Right there in his own essay is the reason.
And that’s exactly where we are with Ajax development today. Sure, yeah, the usability is much better than the first generation DOS apps, because we’ve learned some things since then. But Ajax apps can be inconsistent, and have a lot of trouble working together — you can’t really cut and paste objects from one Ajax app to another, for example, so I’m not sure how you get a picture from Gmail to Flickr. Come on guys, Cut and Paste was invented 25 years ago.
See, Ajax gives you the capability to turn a perfectly good hypertext application into a miserable facsimile of a 1980's PC. And you're not going to fix Ajax by adding a bunch of new APIs. Applications need more constraints, not fewer.
Think how absurd it is that you can't copy a picture from GMail to Flickr. The tools are right there, but the application designers do not leverage them. a) Right click photo in GMail. b) "Copy link location". c) Paste hyperlink into Flickr. d) Flickr either downloads photo from GMail or references it. No new APIs needed -- it's all just hyperlinks.
It's great, and necessary, to extend HTML with rich widgets. We'll never capture them all, declaratively, in a common HTML. I am, even as we speak, constructing a Flash widget. But the web is the platform. Any time I push information deep into my widget -- text that could be searchable, graphics that could be linkable -- and hide it from the web, I've failed to leverage the platform.
5 comments:
But you know what's funny? It seems like I can drag images from any page in Firefox, to a Google Docs document, and it ... works. Always amazes me. No idea what's going on there.
Fully in agreement with your last sentence. Given two similar applications, where one is web-native and the other hides its content behind mouse clicks and such, the web native one will win. Eventually.
I completely agree. For the "sharing between sites" problem, I think microformats might go a long way. In fact, isn't sharing clipboardy stuff like photos what Live Clipboard is all about? Now, I don't think the concrete Live Clipboard implementation is very elegant, but the idea is great and based on microformatting content inside existing (X)HTML pages.
quark -- the Live Clipboard example makes my point exactly. They have reproduced desktop cut and paste, and ignored the web. See, those hCards are embedded in that web page and are inaccessible, as individual resources, on the web.
Web oriented design would model each little hCard on that page as a separate resource. The little icon would link to an underlying vCard. Copy the URL of that link, and paste it into the receiving web page. The receiving page would retrieve the vCard and display it. I can imagine modifying that example above so that when you hover the mouse over one of the hCard entries, a visual cue -- maybe a floating text box -- appears, indicating you can paste a URL there. When you paste, javascript retrieves the URL and if the mime type is text/directory, it's a vCard and we render it.
Voila! The web already does what you want.
Post a Comment